Analyzujte požadavky na CRM systém v prostředí cloud. Systém navrhněte a implementujte. Jako prostředí cloud zvolte platformu Google App Engine. CRM systém bude umožňovat obvyklou funkcionalitu pro tento typ aplikací, to znamená, že systém bude umožňovat: správu firem, osob, obchodních případů, produktů a aktivit. Systém bude také poskytovat různé obchodní reporty, například měsíční a roční obraty firem, hodnocení prodejců, atp. Všechny části projektu budou pečlivě dokumentovány v souladu se zvyklostmi softwarového inženýrství. Systém otestujte na jeho bezchybnou funkci. Součástí práce bude také příručka uživatele a administrátora.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství
Diplomová práce
CRM systém v prostředí cloud Bc. Martin Zahradnický
Vedoucí práce: Ing. Martin Molhanec, CSc.
1. ledna 2013
Poděkování Na tomto místě bych chtěl poděkovat lidem, kteří mne po celou dobu studia a v průběhu tvorby této práce podporovali. Poděkování patří především mé rodině a přátelům, dále pak všem účastníkům testování. Velký dík patří také vedoucímu mé diplomové práce panu Ing. Martinu Molhancovi, CSc. za množství užitečných připomínek, informací, cenných rad a vedení práce.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů. V souladu s ust. § 46 odst. 6 tohoto zákona tímto uděluji nevýhradní oprávnění (licenci) k užití této mojí práce, a to včetně všech počítačových programů, jež jsou její součástí či přílohou a veškeré jejich dokumentace (dále souhrnně jen „Dílo“), a to všem osobám, které si přejí Dílo užít. Tyto osoby jsou oprávněny Dílo užít jakýmkoli způsobem, který nesnižuje hodnotu Díla a za jakýmkoli účelem (včetně užití k výdělečným účelům). Toto oprávnění je časově, teritoriálně i množstevně neomezené. Každá osoba, která využije výše uvedenou licenci, se však zavazuje udělit ke každému dílu, které vznikne (byť jen zčásti) na základě Díla, úpravou Díla, spojením Díla s jiným dílem, zařazením Díla do díla souborného či zpracováním Díla (včetně překladu), licenci alespoň ve výše uvedeném rozsahu a zároveň zpřístupnit zdrojový kód takového díla alespoň srovnatelným způsobem a ve srovnatelném rozsahu, jako je zpřístupněn zdrojový kód Díla.
V Praze dne 1. ledna 2013
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Martin Zahradnický. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci ZAHRADNICKÝ, Martin. CRM systém v prostředí cloud. Diplomová práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.
Abstract The aim of this work is to develop a CRM system on the Google App Engine cloud platform. It acquaints reader to the concept of cloud computing, development platforms and methodologies. Describes the entire development process from introductory study through analysis, design to its implementation, and testing. As a result, there is the functional CRM system and also user’s and administrator’s guides. Keywords Cloud computing, Software as a Service, Customer relationship management, Google App Engine, Java EE, UWE.
Abstrakt Tato práce si klade za cíl vyvinout CRM systém v cloudovém prostředí na platformě Google App Engine. Seznamuje čtenáře s konceptem cloud computingu, použitými vývojovými platformami a metodikami. Popisuje celý proces vývoje od provedení úvodní studie, přes analýzu, návrh až po jeho realizaci a testování. Výsledkem práce je funkční CRM systém, uživatelská příručka a příručka administrátora. Klíčová slova Cloud computing, software jako služba, řízení vztahů se zákazníky, Google App Engine, Java EE, UWE.
ix
Obsah Úvod Motivace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktura práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Použité technologie a koncepty 1.1 Cloud computing . . . . . . . . 1.2 CRM systém . . . . . . . . . . 1.3 Java EE . . . . . . . . . . . . . 1.4 Google App Engine . . . . . . . 1.5 Metodika UWE . . . . . . . . . 2 Úvodní studie 2.1 Deklarace záměru . . . . . 2.2 Rešerše existujících řešení 2.3 Katalog požadavků . . . . 2.4 Návrh architektury řešení 2.5 Analýza rizik . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
1 1 3 4
. . . . .
5 5 11 12 13 15
. . . . .
17 17 19 25 31 31
3 Analýza 37 3.1 Konceptuální datový model . . . . . . . . . . . . . . . . . . . . 37 3.2 Model případů užití . . . . . . . . . . . . . . . . . . . . . . . . 46 4 Návrh 67 4.1 Návrh uživatelského rozhraní . . . . . . . . . . . . . . . . . . . 67 4.2 Výběr implementačního prostředí . . . . . . . . . . . . . . . . . 73 4.3 Architektura systému . . . . . . . . . . . . . . . . . . . . . . . 74 5 Realizace 5.1 Integrační vrstva . 5.2 Datová vrstva . . . 5.3 Prezentační vrstva 5.4 Aplikační logika . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . . xi
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
77 77 80 84 87
6 Testování 91 6.1 White-box testování . . . . . . . . . . . . . . . . . . . . . . . . 91 6.2 Black-box testování . . . . . . . . . . . . . . . . . . . . . . . . . 92 6.3 Testování použitelnosti . . . . . . . . . . . . . . . . . . . . . . . 92 Závěr 97 Zhodnocení dosažených cílů . . . . . . . . . . . . . . . . . . . . . . . 97 Zhodnocení použitých technologií . . . . . . . . . . . . . . . . . . . . 98 Popis další práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Literatura
101
A Seznam použitých zkratek
107
B Obrázky a modely
111
C Uživatelská příručka C.1 První pohled na aplikaci C.2 Hlavní menu . . . . . . C.3 Top-bar menu . . . . . . C.4 Obsah stránek . . . . . C.5 Dialogová okna . . . . . C.6 Zadávání vstupu . . . . C.7 Notifikace systému . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
117 117 117 119 119 120 121 122
D Příručka administrátora 123 D.1 Lokální testování . . . . . . . . . . . . . . . . . . . . . . . . . . 123 D.2 Nasazení CRM systému na GAE . . . . . . . . . . . . . . . . . 124 D.3 Správa aplikace v administrační konzoli . . . . . . . . . . . . . 124 E Obsah přiloženého CD
127
xii
Seznam obrázků 0.1
Hype cycle pro cloud computing, 2012 (zdroj: Gartner [44]) . . . .
1.1 1.2 1.3
Cloud computing - úrovně abstrakce (zdroj: Strategi Co. [45]) . . . 8 Srovnání architektur pro CRM aplikaci (zdroj: Strategi Co. [45]) . 8 Využití hardwarových prostředků: Tradiční model dodávky infrastruktury (zdroj: Vitvar [47]) . . . . . . . . . . . . . . . . . . . . . . . . 10 Využití hardwarových prostředků: Cloudové řešení dodávky infrastruktury (zdroj: Vitvar [47]) . . . . . . . . . . . . . . . . . . . . 10
1.4
2
2.1 2.2 2.3 2.4
Rozhraní CRM systému . . . . . . . . . . . . . . . . Salesforce.com (zdroj: Salesforce.com [41]) . . . . . . Raynet Cloud CRM (zdroj: Raynet [36]) . . . . . . . INEX online CRM systém (zdroj: MAXprojekt [28])
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
18 19 20 21
3.1 3.2 3.3 3.4 3.5 3.6 3.7
Konceptuální datový model . . . . . . . . . . UC model - Aktéři systému . . . . . . . . . . UC model - UC1: CRM Common . . . . . . . UC model - UC2: Web presentation . . . . . UC model - UC3: Front office . . . . . . . . . UC model - UC4: CRM Business Operations UC model - UC6: CRM Reminder . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
38 46 48 52 55 60 65
4.1 4.2 4.3 4.4 4.5 4.6
Návrh navigace v UWE . . . . . . . . . . . . Návrh prezentace v UWE . . . . . . . . . . . Mockup prototyp - Úprava účtu . . . . . . . Logická architektura systému . . . . . . . . . Fyzická architektura systému . . . . . . . . . Distribuce zátěže systému na platformě GAE
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
69 69 70 74 75 76
5.1 5.2
Diagram tříd – datová vrstva . . . . . . . . . . . . . . . . . . . . . Architektura JSF (zdroj: Goncalves [15]) . . . . . . . . . . . . . . .
82 84
B.1 Salesforce.com - Editace příležitosti (zdroj: Salesforce.com [41]) . . 113 B.2 Raynet Cloud CRM - Editace obchodního případu (zdroj: Raynet [36]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 xiii
B.3 B.4 B.5 B.6 B.7 B.8
Mockup Mockup Mockup Mockup Mockup Mockup
C.1 C.2 C.3 C.4 C.5 C.6 C.7 C.8 C.9 C.10 C.11
UI UI UI UI UI UI UI UI UI UI UI
-
prototyp prototyp prototyp prototyp prototyp prototyp
-
Seznam účtů . . . . . . Filtrování seznamu účtů Smazání účtu . . . . . . Detail účtu . . . . . . . Úprava účtu . . . . . . Záložka komunikace . .
Hlavní menu . . . . . . . . . Seznam firem . . . . . . . . Top-bar menu . . . . . . . . Akční tlačítka . . . . . . . . Seznamy . . . . . . . . . . . Dialog smazání firmy . . . . Dialog přidání firmy . . . . Maska vstupního pole . . . Výběr položky s filtrováním Hodnocení . . . . . . . . . . Systémová notifikace . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
114 114 115 115 116 116
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
117 118 119 119 120 120 121 121 122 122 122
D.1 Administrační konzole GAE . . . . . . . . . . . . . . . . . . . . . . 125
xiv
Seznam tabulek 2.1 2.2 2.3 2.4 2.5 2.6
Srovnaní CRM systémů - Standardní funkce . . . Srovnaní CRM systémů - Nadstandardní funkce . Srovnaní CRM systémů - Uživatelské rozhraní . . Srovnaní CRM systémů - Platební modely . . . . Srovnaní CRM systémů - Hodnocení . . . . . . . Vyhodnocení analýzy rizik . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
21 22 23 24 25 36
B.1 Šablona případu užití . . . . . . . . . . . . . . . . . . . . . . . . . 111 B.2 UWE profil 1.9 - Výčet použitých stereotypů (zdroj: Kroiss [24]) . 112
xv
Úvod Motivace V oblasti dodávky ICT1 služeb byl dlouhodobým lídrem tradiční model, kde je software poskytován pod určitou licencí. Poskytovatel vytvoří software a následně ho instaluje na ICT infrastrukturu konkrétního zákazníka. V poslední době se do čela dostává nový způsob dodávky ICT služeb založený na konceptu cloud computingu. Specializovaný poskytovatel provozuje na své vysoce škálovatelné, cloudové infrastruktuře služby (software, úložiště, infrastrukturu), které poskytuje velkému počtu zákazníků prostřednictvím internetu. Službu tak může snadno a rychle zprovoznit a využívat mnohem více uživatelů než u tradičního modelu. Cloud computing je v současnosti jedním z nejsledovanějších a nejvíce diskutovaných témat v oblasti ICT, zahrnuje širokou škálu aspektů a stále se objevují nové. Je zde několik trendů a odhadů do budoucna. Hovoří se dokonce o nahrazení osobního počítače osobním cloudem. Což se již ve velké míře projevuje na používanosti aplikací poskytovaných jako SaaS2 . Příkladem jsou Google Documents, které nahrazují klasickou kancelářskou sadu nástrojů a umožňují editaci a sdílení těchto dokumentů na cloudu. Dokumenty tak nejsou uloženy v osobním počítači a jsou vždy a všem dostupné. A nejenom tyto dokumenty, ale i všechna ostatní data můžeme snadno ukládat a sdílet na cloudu. Například pomocí synchronizovaného datového úložiště (DropBox, Google Drive aj.), které ukládá data uživatelů na cloud. Ty mohou být přístupné klienty na několika různých platformách a operačních systémech (Android, iOS atd.). Společnost Garner [44] dokonce předpovídá, že osobní cloud nahradí osobní počítač jako centrum digitálního života uživatelů již v roce 2014. V privátním sektoru je jedním z předních poskytovatelů SaaS společnost Salesforce.com, která vyvíjí CRM3 systém. Jejich systém používá tisíce společností z celého světa. Data a informace můžeme mít díky cloud computingu k dispozici na různých přístrojích a kdykoli potřebujeme, což tento koncept řadí na přední příčky 1
Information and Communication Technologies Software as a service 3 Customer Relationship Management 2
1
Úvod zájmu společností, veřejnosti i expertů z oblasti vývoje software. O značné popularitě a obsáhlosti cloud computingu hovoří také skutečnost, že přední analytická společnost Gartner vytváří od roku 2010 pro cloud computing samostatnou hype cycle4 křivku. Tyto křivky znázorňují vyspělost předních technologií z různých oblastí. Cloud computing obsahuje tolik různých aspektů, že má křivku vlastní viz obrázek 0.1.
Obrázek 0.1: Hype cycle pro cloud computing, 2012 (zdroj: Gartner [44]) Pozice SaaS na této křivce značí, že se pohybuje ve stavu vyzrálosti. Společnosti tedy už ví jak mohou SaaS pro svůj byznys využívat a v rozhodování o jeho zavedení již nejsou tak konzervativní. Gartner [44] informuje o tom, že SaaS je v podnicích velmi rychle přijímán a osvojován. Na základě toho dále předpovídá, že více než 50% společností bude mít ve svých strategiích v roce 2015 v nějaké formě zahrnuty aplikace založené na SaaS. Cloudová infrastruktura zajišťuje škálovatelnost výpočetních zdrojů. Aplikace na cloudové infrastruktuře se chovají elasticky - pružně reagují na změnu požadavků (poptávku po službách). Hardwarové prostředky jsou optimálně využity. Což je pro určité typy systémů žádoucí. Platebním modelem u cloudových řešení je většinou pay-per-use nebo pay-as-you-go, kde se platí za skutečně využité zdroje (počet uživatelů, výkon, objem uložených dat). Odpadají 4
Hype cycle křivky slouží, dle definice společnosti Gartner [13], jako grafické znázornění vyspělosti a stupně přijetí nových technologií a aplikací. Určují relevantnost jejich nasazení při řešení skutečných byznys problémů a pohled na to, jak se budou v čase vyvíjet. Technologie se může nacházet na křivce v pěti fázích. Po počátečním uvedení prochází fází rozšíření, velkými očekáváními, selháním až po uzrávání a konečnou produktivitu (přechod do mainstreamu).
2
Cíl práce tak nákladné počáteční investice společností do vlastní ICT infrastruktury. A i menší společnosti mohou používat stejně kvalitní, moderní technologie a aplikace jako jejich vetší konkurenti. Model SaaS má do budoucna velmi dobré vyhlídky. Pro mnoho společností může být správnou cestou. Je natolik vyzrálý, že je přijímán a začíná se běžně používat. Je na místě, aby vývojáři software tuto technologii uvážili při modernizaci nebo vývoji nových aplikací a pokusili se jít touto cestou, je-li to účelné.
Cíl práce Předmětem práce je vývoj CRM systému, který bude použitelný pro široké spektrum zákazníků. Systémy CRM slouží pro správu informací, aktivit a interakcí se zákazníkem. Více viz kapitola 1.2 CRM systémy. Systém bude vyvíjen jako TASW5 (typově aplikační software viz Voříšek [48]). Tedy jako obecný CRM systém určený pro použití několika různými společnostmi a uživateli, který je vytvořen na základě generalizace požadavků pro tento typ aplikací. Pro aplikace tohoto charakteru je účelné zvolit model SaaS a vyvinout systém jako webovou aplikaci. Chceme-li systém vyvíjet jako SaaS, musíme pro něj zajistit škálovatelnost výpočetních zdrojů. Nevíme kolik uživatelů bude aplikaci skutečně využívat. Počet uživatelů se může rychle měnit - prudce narůstat i klesat. Potřebnou elasticitu výpočetních zdrojů nám zajistí cloudová infrastruktura. Existují tři základní varianty jejího použití v daném kontextu - nasazení aplikace na existující cloudovou infrastrukturu IaaS6 nebo PaaS7 , anebo vytvoření vlastní cloudové infrastruktury pomocí vlastních zdrojů. Pro vyvíjený CRM systém byla zvolena varianta nasazení na PaaS. Problematika cloud computingu je detailněji popsána v kapitole 1.1 Cloud computing. Cílem práce je analýza, návrh, implementace, testování a nasazení CRM systému, který bude poskytován jako SaaS a bude vyvinut na platformě GAE8 (PaaS) v jazyku Java. Funkcionalita CRM bude obvyklá pro tento typ aplikací. Systém bude umožňovat správu firem, osob, obchodních případů, produktů a aktivit a nad těmito daty bude vytvářet obchodní reporty (analýzy prodeje obchodníků apod.). Požadavky budou upřesněny na základě rešerše existujících řešení. Součástí práce bude rovněž vytvoření uživatelské příručky a příručky pro administrátora systému. 5
Typový aplikační software Infrastructure as a service 7 Platform as a service 8 Google App Engine 6
3
Úvod
Struktura práce Práce je rozdělena do těchto částí: Teoretický úvod Popis konceptů cloud computingu, definice CRM systému, popis platformy Java EE9 a GAE v kapitole 1 Použité technologie a koncepty. Analytická část Zahrnuje úvodní studii práce (kapitola 2), kde je popsán záměr a funkcionalita systému, provedena rešerše existujících řešení a analýza rizik. Dále obsahuje kapitolu 3 Analýza s konceptuálním datovým modelem a modelem případů užití. Poslední částí je návrh (kapitola 4), ve kterém je popsán návrh uživatelského rozhraní, architektury systému a výběr implementačního prostředí. Praktická část Realizace (kapitola 5) a testování systému (kapitola 6) obsahují popis důležitých částí implementace, jednotlivých vrstev aplikace, použitých technologií, tvorbu funkčních testů a testování použitelnosti. Závěr Hodnotí dosažené výsledky a použité technologie. Rozebírá možnosti dalšího rozšíření systému a určuje kroky dalšího vývoje.
9
4
Java Enterprise Edition
Kapitola
Použité technologie a koncepty 1.1
Cloud computing
Jak bylo již zmíněno, systém CRM je vyvíjen jako SaaS na platformě GAE, která poskytuje služby PaaS. Následující část je věnována definici pojmů z oblasti cloud computingu, aby byl zřejmý koncept řešení vyvíjeného systému. Cloud computing přišel také s novým platebním modelem, který je v závěru kapitoly popsán. Pro služby cloud computingu neexistuje zcela jednotná taxonomie, ani není jednotný názor na to, jaké musejí být vlastnosti ICT služby, abychom ji mohly zařadit mezi služby “cloudu” viz Bruckner [5]. Jednou z uznávaných definicí cloud computingu je definice NIST10 [29]. Podle ní je cloud computing model, který umožňuje všudypřítomný, pohodlný, on-demand přístup přes síť ke sdíleným konfigurovatelným výpočetním zdrojům (např. sítím, serverům, datovým úložištím, aplikacím a službám), které mohou být rychle poskytnuty a nasazeny s minimálním úsilím na jejich správu nebo interakci s poskytovatelem služeb. Cloud computing podle ní musí splňovat pět základních charakteristik, musí být poskytnuta jedním ze tří modelů služeb a jedním ze čtyř modelů nasazení.
1.1.1
Základní charakteristiky
On-demand self-service (Samoobslužnost na vyžádání) • uživatelé přistupují a využívají výpočetní prostředky (čas serveru, síťové úložiště atd.) dle jejich okamžité potřeby • přístup je automatický (bez nutnosti interakce s poskytovatelem)
Broad network access (Síťový přístup) • prostředky dostupné přes síť standardními mechanizmy, které podporují použití různých klientů (např. mobilní telefony, tablety, notebooky, pracovní stanice) 10
National Institute of Standards and Technology U.S. Department of Commerce
5
1
1. Použité technologie a koncepty Resource pooling (Pooling zdrojů) • výpočetní prostředky jsou seskupeny tak, aby je bylo možno na základě okamžité poptávky dynamicky přidělit několika zákazníkům (multi-tenant model) • konzument může někdy volit lokaci prostředků na úrovni zemí, států, datových center (např. Amazon EC2)
Rapid elasticity (Rychlá elasticita) • flexibilní, rychlá, automatická dostupnost zdrojů dle okamžité poptávky • pro konzumenta se jeví prostředky jako neomezené (kdykoli, v jakémkoli množství osvojitelné)
Measured service (Měřitelná služba) • cloudové systémy automaticky řídí přidělování zdrojů na základě jejich monitorování a měření • využité zdroje jsou reportovány tak, aby byly transparentní pro obě strany
1.1.2
Modely nasazení
Private cloud (Soukromý cloud) • cloudová infrastruktura je poskytnuta pro exkluzivní použití jedné organizace • spravována je samotnou organizací nebo třetí stranou • může být provozován interně i externě
Public cloud (Veřejný cloud) • cloudová infrastruktura je poskytnuta pro volné užití široké veřejnosti • spravována podnikovou, vládní nebo akademickou organizací • provozována v prostorách poskytovatele cloudu
Community cloud (Komunitní cloud) • cloudová infrastruktura je poskytnuta pro exkluzivní použití specifické komunitě tvořené několika organizacemi • spravována je jednou nebo více organizacemi z komunity nebo třetí stranou • může být provozován interně i externě
Hybrid cloud (Hybridní cloud) • cloudová infrastruktura je kompozicí dvou a více jiných infrastruktur
6
1.1. Cloud computing
1.1.3
Modely služeb
IaaS (Infrastructure as a Service) • poskytovatel dodává zákazníkům jako službu zpracování, úložiště, síť a další výpočetní zdroje, na kterých má možnost nasadit a spustit libovolný software (operační systém, aplikaci) • zákazník nemůže nijak spravovat a ovládat cloudovou infrastrukturu ležící na nižší vrstvě • tuto službu využijí IT architekti a vývojáři software • příklady poskytovatelů: Amazon EC2, GoGrid
PaaS (Platform as a Service) • poskytovatel dodává zákazníkům jako službu aplikační platformu (programovací jazyky, knihovny, služby, nástroje), na které zákazník může vyvinout a nasadit svoji vlastní aplikaci • zákazník nemůže nijak spravovat ani ovládat cloudovou infrastrukturu ležící na nižší vrstvě (sítě, servery, operační systém, úložiště), má ale kontrolu nad nasazenými aplikacemi a konfigurací prostředí aplikačního hostingu • tuto službu využijí vývojáři software • příklady poskytovatelů: Google App Engine, Microsoft Azure
SaaS (Software as a Service) • aplikace jsou přístupné z různých klientských zařízení jak přes rozhraní tenkého klienta jako je webový prohlížeč, tak přes programové rozhraní • zákazník nemůže nijak spravovat ani ovládat cloudovou infrastrukturu ležící a nižší vrstvě (sítě, servery, operační systém, úložiště, aplikační platformu), aplikace může jen customizovat a omezeně spravovat • službu využijí koncoví uživatelé (společnosti, lidé) • příklady poskytovatelů: Salesforce.com, Google Documents
Pro lepší pochopení modelů služeb a jejich správné oddělení popíšeme dva obrázky společnosti Strategi Consulting, které zachycují modely služeb napříč jednotlivými úrovněmi architektonické abstrakce. Na obrázku 1.1 jsou zobrazeny dvě základní vrstvy, v rámci kterých jsou poskytovány sdílené výpočetní zdroje cloudu – infrastrukturní (Infrastructure Layer) a softwarová vrstva (Software Layer), která se dá rozdělit vrstvu aplikační (Application Layer) a vrstvu aplikační platformy (Application Platform Layer). Infrastrukturní vrstva poskytuje zákazníkovi výpočetní výkon, úložiště, rozdělování zátěže mezi virtuální stroje pomocí load balanceru atd. Vrstva aplikační platformy poskytuje zákazníkovi služby, API11 , middleware a nástroje, které zákazník použije na vývoj svých systémů, přičemž o infrastrukturu, která leží pod ní, se vůbec nemusí starat. 11
Application Programming Interface
7
1. Použité technologie a koncepty
Obrázek 1.1: Cloud computing - úrovně abstrakce (zdroj: Strategi Co. [45])
Na aplikační vrstvě je zákazníkovi poskytnut konkrétní systém, který používá pomocí klienta (webového prohlížeče, mobilní aplikace atd.). O infrastrukturu a aplikační platformu se zákazník nijak nestará.
Obrázek 1.2: Srovnání architektur pro CRM aplikaci (zdroj: Strategi Co. [45]) Obrázek 1.2 ilustruje rozdělení architektonických vrstev a porovnává modely služeb cloud computingu s klasickým řešením bez cloudu na konkrétním příkladu, kterým je architektura CRM aplikace. Využijeme-li tradiční model dodávky (viz sloupec „No Abstraction“), pak máme ve své vlastní režii výběr technologií pro vývoj CRM aplikace na všech 8
1.1. Cloud computing vrstvách řešení (viz sloupec „Layer“) – od hardwarové infrastruktury (servery a jejich parametry), přes operační systém, aplikační platformu (DBMS12 , aplikační server atd.), implementaci kódu aplikace (výběr programovacího jazyka, knihoven, frameworků, technologií), až po samotný produkt (funkcionalita, design, platforma). Použijeme-li model IaaS odpadají starosti s vrstvou hardware. U modelu PaaS neovlivníme výběr operačního systému a technologií na aplikační platformě (především DBMS, aplikační server), máme rovněž omezené možnosti výběru programovacího jazyka, technologií a frameworků. U modelu SaaS nezasahujeme ani do infrastruktury, ani vývoje aplikací. Je nám poskytnuta konkrétní aplikace, kterou můžeme jen omezeně spravovat a případně customizovat, jsou-li k tomu dostupné prostředky.
1.1.4
Platební model pro služby cloud computingu
Platebním modelem pro cloudové řešení bývá zpravidla pay-per-use resp. payas-you-go. Zákazník platí za skutečně využité zdroje (výpočetní výkon, úložiště, použité služby, počet uživatelů). Jeden s poskytovatelů IaaS GoGrid [14] uvádí, že se platí za konzumaci těchto služeb: objem datového přenosu za měsíc, výpočetní výkon za hodinu (počet instancí za hodinu), užití RAM13 za hodinu a využitou kapacitu úložiště za měsíc. Platební model PaaS je podobný předešlému. Ceník GAE [16] uvádí, že pro každou aplikaci jsou nastaveny kvóty na denní využití zdrojů a služeb. Pokud běh aplikace nepřesáhne dané kvóty, je v provozu zdarma. Pokud ale některou kvótu přesáhne, začíná se platit. Platí se za výpočetní výkon za hodinu (počet instancí za hodinu), velikost úložiště za měsíc, za 1 GB odchozího datového přenosu, počet operací nad databází a za použití různých API (např. počet odeslaných emailů nad denní kvótu 100). Platby se ovšem liší dle poskytovatelů PaaS. U modelu SaaS se ve většině případů platí za jednoho uživatele za měsíc. Poskytovatel může mít víc cenových kategorií, které se liší v závislosti na rozšiřujících službách nebo jejich kvalitě. Takový model má například poskytovatel CRM Salesforce.com [39]. Tyto platební modely osvobozují zákazníky od velkých fixních nákladů, starostí s plánováním nákupu a údržby hardware a transformují je do menších variabilních nákladů. U tradičního modelu dodávky ICT jsou investice do hardwarových zdrojů skokového charakteru, viz obrázek 1.3. Už prvotní investice je vysoká. Dále předpokládáme určitý vývoj poptávky po hardwarových zdrojích a v naplánovaných intervalech investujeme do jejich rozšíření. U tohoto modelu mohou nastat dvě extrémní situace. U první, která nastává vždy, nejsou zdroje plně 12 13
Database Management System Random Access Memory
9
1. Použité technologie a koncepty využity (nízká poptávka, velká kapacita). Druhá situace je kritická. Nastane, překročí-li poptávka možnosti našich zdrojů (vyšší poptávka, nedostatečná kapacita). Aplikace pak není výkonná, uživatelé nejsou spokojeni a můžeme přijít o zákazníky.
Obrázek 1.3: Využití hardwarových prostředků: Tradiční model dodávky infrastruktury (zdroj: Vitvar [47]) U cloudového řešení dodávky odpadá zatížení způsobené velkou prvotní investicí do vybudování ICT infrastruktury, viz obrázek 1.4. Od začátku používání platíme jen za to, co skutečně spotřebujeme (pay-as-you-go). Nemůže nastat kritická situace. Infrastruktura roste flexibilně spolu s poptávkou po našich službách. Zde vidíme hlavní výhody cloudového řešení.
Obrázek 1.4: Využití hardwarových prostředků: Cloudové řešení dodávky infrastruktury (zdroj: Vitvar [47]) 10
1.2. CRM systém
1.2
CRM systém
Dohnal [11] říká, že CRM (řízení vztahů se zákazníky) zahrnuje pracovníky, podnikové procesy a technologii IS/ICT14 s cílem maximalizovat loajalitu zákazníků, a v důsledku toho i ziskovost podniku. Je součástí podnikové strategie a jako takové se stává součástí podnikové kultury. Technologicky stále více využívá potenciálu a možností internetu. Řízení vztahů se zákazníky je podle něj postaveno na čtyřech základních pilířích viz Chlebovský [7]: • Lidé: aktivní účast zaměstnanců • Procesy: CRM sjednocuje procesy marketingu, prodeje a služeb, optimalizované procesy CRM zefektivňují • Technologie: nástroje umožňující uplatnění moderního řízení vztahů se zákazníky i při velkém počtu oslovovaných klientů • Data: sběr dat, možnosti jejich uchování, vyhledávání, třídění a analýz jejich závislostí vede k plnohodnotnému CRM
Pojem „CRM systém“ definuje Hommerová [19] jako soubor hardwarových a softwarových technologií a nástrojů podporujících celkovou strategii podniku, vedoucí k poznávání zákazníků, posílení jejich loajality, zvýšení zájmů o další produkty a služby podniku. Systém používá ke sběru dat různé informační zdroje (vnitropodnikové i vnější), které poskytují informace o zákaznících, produktech, službách, marketingové informace o kampaních, jejich výsledcích, stejně jako informace získané v rámci komunikace se zákazníkem. Úkolem je i předání těchto informací kompetentním pracovníkům. Cílem CRM je vytvoření vztahu mezi firmou a zákazníkem, který je prospěšný pro obě strany. Řízení vztahů se zákazníky je obchodní strategií, ve které hrají informační technologie podpůrnou roli. Často ale bývá chápáno mylně – jako softwarový prostředek nebo podniková filozofie. Dle průzkumů Hommerové [19] převažuje přístup jako k podnikové filosofii založené na komunikaci se zákazníkem a na obecném marketingovém přístupu. Ve skutečnosti se jedná o spojení obou. Výzkum [3] týkající se řízení vztahů se zákazníky uvádí hlavní nevýhody zavedení CRM v podniku. Jsou jimi finanční, časová a personální náročnost (vysoká cena, zaškolení personálu apod.) a nárůst administrativní činnosti. Dopady těchto nevýhod může zmírnit volba vhodného CRM systému. Zvolíme-li systém, který poskytován jako SaaS s platebním modelem payas-you-go, pak odpadají vysoké pořizovací a časové náklady (investice do ICT infrastruktury a vývoje systému). Personální náročnost můžeme, z hlediska zaškolování, ovlivnit pouze vývojem kvalitního uživatelského rozhraní a provedením testováním použitelnosti. Výsledkem by pak měla být CRM aplikace, kterou budou uživatelé rádi používat. 14
Information Systems / Information and Communication Tech.
11
1. Použité technologie a koncepty Přesně takový systém, který by vyhovoval širokému spektru zákazníků, respektuje moderní trendy a potlačuje hlavní nevýhody zavedení CRM, bude na snaze vyvinout.
1.3
Java EE
Pro implementaci systému byla zvolena platforma Java EE, která je tvořena souhrnem specifikací (JSR15 ) a technologií postavených nad základní verzí Java SE16 . Umožňuje vývoj distribuovaných, robustních, výkonných, škálovatelných a vysoce přístupných webových a podnikových aplikací. Platforma Java EE poskytuje otevřené standardy, které jsou implementovány několika komerčními (Websphere, WebLogic) i open source (GlassFish, JBoss, Hibernate atd.) frameworky, jež zabezpečují transakční zpracování, držení stavu komponent, persistenci objektů, bezpečnost a tak dále viz Goncalves [15]. Jednotlivé specifikace jsou implementovány různými kontejnery (běhovými prostředími pro Java EE), které hostujícím komponentám poskytují své služby – správu životního cyklu, dependency injection, aj. Modelem Java EE aplikací je distribuovaný vícevrstvý model viz Jendrock [21]. Aplikační logika je rozdělena na několik komponent, které jsou nasazeny na různých zařízeních (strojích) v závislosti na jejich funkci a vrstvě vícevrstvého Java EE prostředí, na kterou komponenta patří. Aplikace jsou většinou považovány za třívrstvé resp. čtyřvrstvé, protože jsou distribuovány na tři místa: klientské zařízení (klientská vrstva), Java EE server (webová a business vrstva) a databázový server (EIS17 vrstva). Klientskou vrstvu tvoří aplikace, pomocí kterých klient komunikuje s Java EE aplikací. Klient odesílá požadavky na Java EE server, na kterém je aplikace nasazen. Server sestaví a odešle odpověď. Klientem může být buď aplikační klient (aplikace na zařízení klienta) nebo webový klient (tenký klient). Webový klient se skládá ze dvou částí. Dynamicky generované stránky (HTML18 , XML19 ) komponentami běžícími na webové vrstvě aplikace a webový prohlížeč na straně klienta, který stránky renderuje. Webovou vrstvu tvoří komponenty, které obsluhují požadavky a komunikují s nižšími vrstvami (business a databázovou vrstvou). Vrstva zajišťuje generování webových stránek ve formátu HTML, XML aj., obsluhu session klientů, navigaci mezi stránkami, držení stavu a vykonává i logiku. Standardem Java EE je pro tuto vrstvu JSF20 framework, pomocí něhož je rozdělen vývoj webové části aplikace na UI21 (tagy v HTML stránkách) a aplikační logiku 15
Java Specification Request Java Standard Edition 17 Enterprise Information System 18 HyperText Markup Language 19 Extensible Markup Language 20 JavaServer Faces 21 User Interface 16
12
1.4. Google App Engine (Java bean komponenty). Dalším standardem je framework Facelets, který je součástí JSF od verze 2.0. Slouží k tvorbě šablon stránek. Existuje celá řada dalších frameworků pro vývoj webové vrstvy, které nejsou součástí Java EE specifikace. Business vrstva slouží k implementaci aplikační logiky. Standardy této vrstvy jsou Java Persistence Entities (třídy definující datové entity) a EJB22 beany (aplikační logika). Vrstva komunikuje s jinými systémy pomocí webových služeb (standardy JAX-WS23 a JAX-RS24 ) a s databázemi. Vrstvu EIS tvoří okolní systémy, ze kterých aplikace čerpá data. Může se jednat o databázové systémy nebo jiné systémy (ERP25 apod.), které slouží jako datový zdroj pro aplikaci.
1.4
Google App Engine
Platforma GAE poskytuje PaaS služby pro vývojáře software. Použitím GAE odpadají starosti s infrastrukturou systému. Nemusíme se starat o hardware, síť, úložiště, škálovatelnost atd. Pro vývoj aplikací slouží speciální SDK26 , ze kterého je možno aplikaci přímo nahrát na GAE a nasadit ji tak do testovacího nebo ostrého online provozu. Na platformě existují běhová prostředí pro tři programovací jazyky: Java, Python a Go. Aplikace je možno nasadit i bezplatně. Platební model je standardní pro služby cloud computingu – pay-as-you-go – platí se za spotřebované služby, které překročí bezplatné kvóty. Nasazené aplikace se dají spravovat v administrační konzoli, jejíž součástí je zobrazení reportů, kvót, log souborů, správa verzí, úložiště, nastavení plateb, přístupových práv pro vývojáře atd.
1.4.1
Aplikační prostředí
Mezi vlastnosti a funkce platformy GAE [17] patří provoz dynamických webových aplikací, podpora standardních webových technologií, perzistentní úložiště (spouštění dotazů, řazení dat a podpora transakcí), automatická škálovatelnost, load balancing, API pro autentizaci uživatelů a posílání emailů pomocí Google Accounts, vývojové prostření podporující všechny funkce GAE umožňující jeho lokální simulaci, fronta pro spouštění asynchronních úkolů, spouštění naplánovaných úloh (cron jobs) v určených časových intervalech. Existují tři způsoby pro persistenci dat. Prvním je App Engine Datastore, který poskytuje NoSQL objektovou databázi bez schématu s dotazovacím strojem a atomickými transakcemi. Další možností je Google Cloud SQL, která 22
Enterprise Java Beans Java API for XML Web Services 24 Java API for RESTful Web Services 25 Enterprise Resource Planning 26 Software Development Kit 23
13
1. Použité technologie a koncepty poskytuje klasickou relační SQL databázi založenou na MySQL RDBMS27 . Poslední je Google Cloud Storage, který poskytuje služby (REST28 API) pro uložení objektů a souborů do velikosti terabajtů. Poslední dvě jsou placené. App Engine podporuje integraci s Google Accounts (Users API). Aplikace umožňuje přihlášení uživatele pomocí Google účtu, zobrazení jeho jména a emailu. Má-li uživatel založen takový účet, nemusí si vytvářet speciální účet pro přihlášení do aplikace. Další služby a API, které platforma zahrnuje jsou URL Fetch (přístup aplikací k externím zdrojům v síti internet), Mail API (odesílání emailů z aplikace), Image Manipulation (změna velikosti obrázků, rotace,. . . ), Memcache API (k aplikaci je asociována key-value cache paměť, která je dostupná všemi instancemi aplikace). Škálovatelnost aplikací je na App Engine zajištěna tzv. „load balancerem“. Ten přiděluje, dle aktuálního zatížení, klientům instance aplikace, které je mají obsluhovat (přidává nové instance nebo ubírá a určuje, kterého klienta obslouží jaká instance). Každá nová instance aplikace je vytvořena na novém virtuálním stroji JVM29 . Proces vytváření nových instancí je časově velmi náročný. Inicializace aplikace při prvním požadavku nebo při vytvoření nové instance se nazývá „loading request“. Vysoká časová náročnost se dá zmírnit použitím lazy inicializace (při požadavku se načítá pouze nutná část zobrazených dat), sdílením dat náročných na výpočet mezi jednotlivými instancemi v Memcache (kde jsou rychle načtena při startu jiné JVM) nebo použitím lightweight knihoven a konfigurací.
1.4.2
Vývoj v jazyku Java
Pro vývoj v jazyku Java lze použít obvyklé vývojové nástroje a API. Prostředí App Engine [17] poskytuje Java 6 JVM, rozhraní Java Servlet, rozhraní pro přístup k úložišti Datastore a další služby jako JDO30 , JPA31 , JavaMail či JCache. Pro vývojové prostředí Eclipse IDE32 existuje zásuvný modul, který přidává podporu pro vývoj aplikací na GAE v Javě. Plugin zahrnuje kompletní App Engine SDK, které umožňuje lokální testování i nasazení aplikací na platformu GAE. Jsou dostupné i pluginy pro vývoj v ostatních IDE. Platforma GAE používá pro webové aplikace standard Java Servlet. Obsluha požadavků klienta aplikace probíhá na základě zpracování servletů, JSP33 stránek a deskriptoru nasazení (web.xml). 27
Relational Database Management System Representational State Transfer 29 Java Virtual Machine 30 Java Data Objects 31 Java Persistence API 32 Integrated Development Environment 33 JavaServer Pages 28
14
1.5. Metodika UWE 1.4.2.1
Nepodporované standardy
Existuje několik omezení a pro vývoj v Javě na platformě GAE [17]. Běhové prostředí obsahuje určité restrikce, které jsou implementovány přímo v JVM. Aplikace může použít jakýkoli bytecode pro JVM nebo knihovnu, neporušujeli některou z restrikcí (např. bytecode, který se pokusí otevřít socket pro zápis do souboru způsobí výjimku). App Engine nepodporuje veškeré komponenty Java EE specifikace, jen některé z nich: JDO, JPA, JSF, JSP, Java Servlet API, JAXB34 , JAX-WS, JavaMail, API pro zpracování XML – DOM35 a SAX36 . I u těchto komponent však existují různá omezení nebo jejich zprovoznění vyžaduje dočasné obejití v kódu. Nejsou podporovány tyto důležité části Java EE: EJB, JDBC37 , JMS38 , JNDI39 a další. Ze známých webových frameworků a knihoven nejsou podporovány: – Hibernate, Tapestry 5.1, ICEFaces Polo-podporovanými, které vyžadují dočasné obejití v kódu, jsou: – Wicket, RichFaces, PrimeFaces, JBoss Seam, Guice, Grails, Spring Security Podporovanými jsou: – Spring MVC, Struts, MyFaces, Facelets, Google Web Toolkit
1.5
Metodika UWE
Metodika UWE40 poskytuje sadu elementů specifických pro webovou doménu určených pro modelování webových systémů viz Kroiss [24]. Podobně jako ostatní přístupy pro modelování webu je i UWE založeno na principu oddělení zodpovědností (Separation of Concerns). Modely jsou tvořeny v různých fázích vývojového procesu od sběru požadavků přes analýzu, návrh a implementaci a představují různé pohledy na webovou aplikaci – pohled na obsah, navigační strukturu, prezentaci viz Rossi [38]. Hlavní charakteristikou UWE je použití jazyku UML41 2.0 jako základu pro tvorbu modelů, který rozšiřuje o nové prvky. Elementy metamodelu UWE jsou potomky elementů metamodelu UML viz Koch [22]. Metodika UWE ale není jen modelovací jazyk pro grafické znázornění webových aplikací a metamodel elementů. Jejím cílem je pokrýt celý proces vývoje webových aplikací. Z tohoto důvodu poskytuje modelem řízenou metodiku (model-driven methodology), podporu pro tvorbu modelů a podporu pro automatické generování 34
Java Architecture for XML Binding Document Object Model 36 Simple API for XML 37 Java Database Connectivity 38 Java Message Service 39 Java Naming and Directory Interface 40 UML-based Web Engineering 41 Unified Modeling Language 35
15
1. Použité technologie a koncepty kódu. Generování webových aplikací není zatím plně automatizované (jako je tomu např. u metodiky WebML42 viz Ceri [6]), je ve fázi vývoje. Modely lze tvořit ve dvou CASE43 nástrojích po instalaci pluginů, ve kterých je specifikován UWE profil – ArgoUML (plugin ArgoUWE) a MagicDraw (MagicUWE). Podle UWE je prvním krokem vývoje webových systémů identifikace požadavků, které jsou popsány modelem požadavků (Requirements model) viz Rossi [38]. V tomto modelu je pomocí diagramu případů užití hrubě popsána funkcionalita. Jednotlivé případy užití mohou být podrobněji znázorněny pomocí diagramů aktivit. Metodika UWE případy užití dále člení na navigační (prohlížení obsahu stránek), procesní (byznys požadavky transakčního charakteru), adaptační (customizace systému uživatelem) nebo observační (sledování akcí uživatele) viz Kozuruba [23]. V diagramu bývá takový případ užití označen buď klasickým stereotypem jazyka UML nebo zástupným symbolem v podobě ikony (viz tabulka stereotypů UWE profilu v příloze B.2). Na pomezí mezi analýzou a návrhem webového systému stojí model obsahu (Content model), jehož cílem je specifikace konceptů aplikační domény, které tvoří především obsahovou část systému. Často ovšem zahrnují i webové entity představující uživatelský profil a kontext, které jsou potřebné ke customizaci systému. Pro tyto entity se zpravidla tvoří separátní „User model“. Na základě předešlých modelů je následně vytvořen model navigační (Navigation model), jež reprezentuje navigační (hypertextovou) strukturu systému. Je tvořen navigačními uzly (NavigationNode) a odkazy resp. orientovanými hranami (Link), které uzly spojují a představují směr, kterým může uživatel mezi uzly přecházet. Podrobnou strukturu všech modelů a jejich elementů popisuje Kroiss [24] v referenční příručce UWE. Podle metodiky je prvním krokem tvorby navigačního modelu tzv. počáteční model navigační struktury, který vznikne transformací tříd a vazeb z modelu obsahu na navigační třídy a odkazy. V dalším kroku je model rozšířen o procesní třídy, které reprezentují byznys procesy a jsou odvozeny od „nenavigačních“ případů užití. Autoři metodiky doporučují rozdělení navigačního modelu do více diagramů pokrývajících různé aspekty systému. Procesy figurující v navigačních diagramech bývají následně rozkresleny do procesního modelu (Process model). Nad navigačním modelem je sestaven prezentační model (Presentation model). Ten představuje abstraktní kompozici uživatelského rozhraní. Neřeší přesné rozestavení prvků webových stránek, layout systému a design. Namísto toho popisuje základní strukturu UI tím, že specifikuje elementy obsažené v jednotlivých navigačních uzlech – textová pole, odkazy, tlačítka atd. Model je vizualizován jako diagram tříd. Jeho základním elementem je prezentační třída, která je založena přímo na nějakém navigačním uzlu navigačního modelu. Prezentační třída je kompozicí UI elementů, které jsou jejími vnořenými třídami a označují se různými stereotypy (viz stereotypy UWE v příloze B.2). 42 43
16
Web Modeling Language Computer-Aided Software Engineering
Kapitola
Úvodní studie V úvodní studii je uveden záměr této práce. Následně je provedena rešerše existujících řešení, odvozeny požadavky na systém, popsán návrh architektury systému a analyzována rizika spojená s vývojem.
2.1
Deklarace záměru
Záměrem této práce je vývoj obecného CRM systému určeného pro mnoho klientů – velké podniky i malé firmy z různých odvětví. Důležitými vlastnostmi finálního produktu jsou cenová dostupnost (nízké pořizovací náklady), použitelnost aplikace (propracované UI) a okamžitá dostupnost aplikace (online na vyžádání). Systém bude vyvinut jako webová aplikace. Bude dostupný online přes webový prohlížeč tak, aby jej mohlo využívat více klientů zároveň. Cílem je získávat nové a nové klienty v neomezené míře. Pro zajištění maximální dostupnosti aplikace, je nutné, aby narůstající počet klientů neměl vliv na funkcionalitu aplikace (odezvu, výpadky aplikace). Pokud bychom aplikaci nasazovali na vlastní ICT infrastrukturu, museli bychom zajistit to, že bude působit jako by měla neomezené zdroje (výpočetní, kapacitní). Tyto starosti přenecháme společnosti Google tím, že nasadíme aplikaci na cloudovou platformu GAE, jejíž infrastrukturu tvoří obrovské množství výpočetních uzlů v datových centrech po celém světě. Okamžitá dostupnost aplikace a cenová dostupnost bude zajištěna tím, že bude aplikace vyvinuta jako SaaS. Budeme se držet principů SaaS z definice NIST (viz kapitola 1.1). Uživatel bude moct aplikaci zprovoznit sám, na vyžádání (princip On-demand self-service). Čili ve webovém rozhraní přístupném všem uživatelům, zvolí možnost „začít používat aplikaci“ (alternativně „vyzkoušet aplikaci“) a aplikace mu bude ihned k dispozici pro používání (na vyzkoušení). Cenovou dostupnost zajistíme použitím platebního modelu pay-as-you-go. 17
2
2. Úvodní studie Klient (společnost, firma) bude platit určitý finanční obnos za každého uživatele používajícího aplikaci za měsíc (x Kč/uživatel/měsíc). Přesný platební model bude zvolen po dokončení vývoje. Velký důraz bude kladen na návrh uživatelského rozhraní. Aplikace musí působit přehledně, být jednoduchá na ovládání a na klienty musí působit přirozeně. Pouze to může zajistit její úspěch na trhu. Uživatelské rozhraní bude obsahovat moderní prvky webového rozhraní jako jsou modální okna (dialogy), nástěnka, grafy apod. Dle principů snadné navigace bude používat obrázky u položek menu. Nad celým systémem CRM budou existovat tři logicky oddělené části resp. rozhraní (viz ilustrace 2.1): 1. Webová prezentace „WEB“: Poskytuje běžnému návštěvníkovi webu informace o CRM systému a rozhraní pro vstup do aplikace (jak pro registrované uživatele, tak pro návštěvníky, kteří si chtějí aplikaci vyzkoušet). 2. Aplikace „CRM“: Aplikace, kterou využívají uživatelé (pracovníci klientských společností). Spravují zde účty svých zákazníků, osoby, obchodní případy atd. 3. Front office „FO“: Rozhraní pro správu aplikace a klientských společností, kterou provádí manažeři a administrátoři z týmu, který systém CRM vyvíjí a prodávají.
Obrázek 2.1: Rozhraní CRM systému U jednotlivých částí systému jsou v uvozovkách uvedeny jejich pracovní jména. Pomocí těchto jmen se na tyto části systému budeme v textu odkazovat. Označení CRM systém (resp. „CRMaaS“ nebo „CRM App“) budeme 18
2.2. Rešerše existujících řešení používat pro celý systém – všechny jeho části. Upřesníme i názvy dosud zmíněných aktérů: • Klient: klientská společnost, firma, organizace nebo osoba, které dodáváme CRM • Uživatel (User): zaměstnanec klienta, který pracuje s CRM aplikací • Návštěvník (Visitor): potenciální klient, který prohlíží WEB a může si vyzkoušet demo verzi CRM • Manažer (Manager): manažer systému, který spravuje klienty ve FO • Admin: administrátor systému, který spravuje aplikaci ve FO
2.2
Rešerše existujících řešení
V této části je provedena rešerše tří CRM systémů dostupných přes webové rozhraní. U každého řešení jsou popsány standardní funkce, rozšiřující funkce, uživatelské rozhraní, platební model a provedeno jejich hodnocení.
2.2.1
Salesforce.com
Salesforce.com [40] je americká společnost, která se zabývá poskytováním služeb v cloudovém prostředí. Vlajkovou lodí je stejnojmenné CRM řešení (viz obrázek 2.2), na kterém vybudovala své podnikání. Nyní nabízí několik dalších cloudových služeb (např. PaaS systém Force.com rozšiřující Salesforce.com).
Obrázek 2.2: Salesforce.com (zdroj: Salesforce.com [41]) Systém CRM Salesforce.com je poskytován formou SaaS. Cloudové prostředí je tvořeno vlastními výpočetními zdroji, servery, které jsou umístěny 19
2. Úvodní studie v několika datových centrech rozmístěných po celém světě. Salesforce.com má přes sto tisíc zákazníků z celého světa viz [40] a jeho roční obrat přesahuje miliardu dolarů viz [42].
2.2.2
Raynet cloud CRM
Raynet [37] je česká společnost, která se zabývá vývojem software a zejména jejich mateřského produktu Raynet Cloud CRM (viz obrázek 2.3). V roce 2010 dostala ocenění od nezávislé auditorské společnosti Delloite jako 4. nejprogresivnější technologická firma ve střední Evropě v kategorii „Rising Stars“.
Obrázek 2.3: Raynet Cloud CRM (zdroj: Raynet [36])
Raynet Cloud CRM je poskytován jako SaaS. Všichni klienti přistupují k systému skrze jedno webové rozhraní a nemusejí se starat o nasazení systému a jeho údržbu. Není známo na jaké infrastruktuře je systém nasazen, společnost tyto informace neposkytuje. Může se jednat o interní i externí infrastrukturu. Může jít i o cloudovou infrastrukturu. Systém používají desítky klientů na českém trhu. Do budoucna má velký potenciál.
2.2.3
INEX online CRM systém
INEX online CRM systém [28] je produktem české společnosti MAXprojekt s.r.o., která se orientuje výhradně na vývoj tohoto produktu (viz obrázek 2.4). Systém je poskytován tradičním způsobem. Klient si zaplatí licenci za tento software, nasadí ho na vlastní hardwarovou infrastrukturu a zpřístupní ho přes síť internet všem svým pracovníkům. Jeho údržbu musí zajistit vlastními zdroji. Tento systém používají desítky především českých klientů. 20
2.2. Rešerše existujících řešení
Obrázek 2.4: INEX online CRM systém (zdroj: MAXprojekt [28])
2.2.4
Porovnání CRM systémů
Standardní funkce Všechny tři systémy poskytují standardní funkcionalitu. Tabulka 2.1 uvádí přehled základních funkcí jednotlivých systémů. V systémech se liší pojmenování a smysl některých základních entit jako například „Account“ (účet) resp. „Contact“ (kontakt) v Salesforce.com je ve zbylých systémech ekvivalentem pro „Firma“ resp. „Osoba“. V tomto směru je Salesforce.com obecnější. Salesforce.com
Raynet cloud CRM
INEX online CRM systém
Standardní funkce Správa účtů, kontaktů, obchodních příležitostí, kampaní, smluv, nástěnek, dokumentů, prognóz prodeje, událostí, úkolů, uživatelských rolí, nápadů, produktů. Tvorba vlastních reportů. Kalendář. Chat se spolupracovníky. Nápověda na jednotlivých stránkách, kontextové nápovědy u jednotlivých stránek, entit a panelů. Připomínač aktivit (úkolů a událostí). Nástěnka. Správa firem, osob, obchodní případů, nabídek, objednávek, projektů, produktů, ceníků, úkolů, aktivit, dokumentů. Administrace uživatelů a nastavení oprávnění. Kalendář. Komentování obchodních entit (chat). Nápověda na jednotlivých stránkách. Připomínač aktivit (úkolů a událostí). Reporty. Nástěnka. Správa firem, osob, příležitostí, nabídek, objednávek, faktur, projektů, úkolů, aktivit, produktů a jejich kategorií, kampaní, dokumentů, reportů, benefitů. Administrace skupin, uživatelů a nastavení oprávnění. Kalendář. Chat. Připomínač aktivit, diskuzí a chatu.
Tabulka 2.1: Srovnaní CRM systémů - Standardní funkce 21
2. Úvodní studie Nadstandardní funkce Všechny systémy poskytují různé nadstandardní funkce jako integraci do dalších systémů, možnost použití mobilního klienta, migraci dat ze starého systému, importy dat apod. (viz tabulka 2.2). Nejvíce rozšiřujících služeb nabízí Salesforce.com. I Raynet jde moderní cestou, poskytuje nad systémem REST API. Salesforce.com
Raynet cloud CRM
INEX online CRM systém
Nadstandardní funkce Propojení s Data.com (vyhledávání nad databází účtů a kontaktů). Chat, do kterého je možné zapojit i zákazníky, které klienti Salesforce.com v systému evidují. Následování uživatelů (podobná funkcím „follow“, „followers“ na Twitteru). Správa úloh (chyb a připomínek) a jejich řešení. Customizovatelnost stránek (nastavení zobrazení panelů na stránkách apod.). Tvorba vlastních reportů, integrace e-mailu s aplikacemi Gmail a Outlook, mobilní přístup, tvorba vlastních aplikací a webových stránek nad systémem. Integrace s Google AdWords (aplikace pro sledování reklamních kampaní). Podporuje standard iCalendar (možnost synchronizace kalendáře s dalšími zařízeními). Poskytuje REST API (možnost integrace s aplikacemi třetích stran). Mobilní přístup k systému přes zařízení na platformách iOS, Android, BlackBerry, Windows Phone 7. Import dat ze souborů v binárním formátu XLS nebo formátu CSV44 . Integrace s účetními systémy (Pohoda, Money S3/S5 apod.) a ERP systémy (QI, K2, Helios apod.). Ovšem není uvedeno, zda je integrace s těmito systémy již implementována a jestli je poskytována za příplatek nebo zdarma.
Tabulka 2.2: Srovnaní CRM systémů - Nadstandardní funkce
Uživatelské rozhraní Uživatelské rozhraní je důležitým kritériem pro výběr systému a spokojenost klientů. U každého systému jsou použity moderní prvky UI, ale obsahují určité nedostatky, které by se daly určitým způsobem vylepšit. V tomto tvrzení a následujícím srovnání UI systémů (viz tabulka 2.3), vycházím z obecných principů návrhu uživatelského rozhraní podle Nielsena [32] a Kruga [25] a jednotlivé systémy podle nich subjektivně hodnotím. V rešerši jsou srovnána webová rozhraní aplikací, vyvíjený systém bude rovněž webovou aplikací. Celkově působí nejlepším dojmem rozhraní Raynet Cloud CRM. I tomu ale můžeme vytknout některé nedostatky - položky hlavního menu jsou přístupné až po rozbalení určité kategorie, do nekonečna se otvírají záložky. V systému Salesforce.com nejsou zvýrazněna tlačítka „potvrdit“ oproti tlačítkům „zrušit“, komplexita některých stránek evokuje nepřehlednost. Minimalistický design systému INEX nepůsobí přehledně, na stránce je příliš mnoho informací, některé ikony neodpovídají současným konvencím UI, chybí ikony u položek a podpoložek hlavního menu. 22
2.2. Rešerše existujících řešení
Salesforce.com
Raynet cloud CRM
INEX online CRM systém
Uživatelské rozhraní Na obrázku 2.2 můžeme vidět rozložení stránky (layout) aplikace Salesforce.com, hlavní menu je řešeno jako jednoúrovňové vertikální, položky menu je možné nastavit. Nápověda je na každé stránce a i u panelů. Salesforce.com je velmi komplexní systém, například stránka s detailem příležitosti obsahuje mnoho informací, což nepůsobí přehledně. Stránku ale můžeme customizovat a zakázat zobrazení některých panelů. Po úpravě záznamu je upravená položka barevně odlišena. Tlačítko pro uložení změn ale zvýrazněno není, navíc každý panel má vlastní (viz obrázek B.1). Uživatel se zde může ztrácet. Připomínač funguje formou vyskakovacích oken, což nemusí být praktické. Layout aplikace Raynet je velmi přehledný (viz obrázek 2.3). Hlavní menu je řešeno formou harmoniky (accordion menu), takže nejsou vždy viditelné všechny jeho položky a uživatel musí rozklikávat kategorie. Každé položce menu ale přísluší výstižný obrázek a to naopak práci uživatele usnadní. V aplikaci je obecně hodně ikon a obrázků, které uživateli usnadní orientaci. Každá otevřená položka se zobrazí v záložkách systému. Pokud záložky uživatel průběžně nezavírá, jejich počet roste a view se stává nepřehledným (viz obrázek 2.3). Po editaci nějaké položky se u jména entity zobrazí text „změněno“ a zároveň dojde ke zvýraznění tlačítka „uložit“ (jedno pro celou stránku). Tato situace je pro uživatele přehledná (viz obrázek B.2). Aplikace INEX (viz obrázek 2.4) působí jako desktopová aplikace. V horní části obrazovky je mezi dvěma logy zbytečně moc nevyužitého místa. Hlavní menu s kategoriemi položek je netradičně v levém dolním rohu a položky se otevírají v prostoru nad ním. U kategorií a položek postrádám obrázky. Na obrázku je otevřena kategorie „adresář“ a rozbalena podkategorie „firmy“. Pokud máme v seznamu firem víc záznamům než dva, které jsou na ukázce, a rozbalíme strom firem se všemi položkami, nevejdou se položky na stránku. Jak je řešena tato situace není bohužel známo. Mezi tlačítky „storno“, „uložit“ a „smazat“ v kontextu záznamů není žádný vizuální rozdíl, mohou být snadno zaměněna. Po změně záznamu není tlačítko „uložit“ nijak zvýrazněno.
Tabulka 2.3: Srovnaní CRM systémů - Uživatelské rozhraní
Platební modely Jediný systém, který je dodáván tradičním způsobem je INEX. Zbylé dva jsou poskytovány jako SaaS a uplatňují platební model pay-as-you-go (platí se za skutečně použité zdroje, u modelu SaaS je to cena za každého uživatele, který aplikaci používá daný měsíc). Pořizovací náklady a náklady na správu jsou samozřejmě menší u SaaS systémů. Nejlevnější variantou ze srovnávaných systémů je Salesforce.com (viz tabulka 2.4), za který menší firma s pěti pracovníky zaplatí měsíčně cca 500 Kč, ročně 6 000 Kč (nemá ale k dispozici veškerou funkcionalitu a je omezena pouze na pět uživatelů). Raynet by ve stejném případě stál měsíčně 2 500 Kč, ročně 30 000 Kč. INEX má vysoké pořizovací náklady (v řádech desítek i stovek tisíc korun) a vysoké ceny za servis a podporu. V modelovém případě by 23
2. Úvodní studie klient systému INEX zaplatil za měsíční správu serveru stejnou částku jako za používání systému Raynet včetně veškerého servisu – 2 500 Kč. V této situaci je zřejmé, který poskytovatel se více vyplatí. Salesforce.com
Raynet cloud CRM INEX online CRM systém
Platební modely x$/uživatel/měsíc po dobu používání systému dle zvoleného tarifu: - Contact Manager (Správa kontaktů pro maximálně 5 uživatelů) - 5$ - Group (Základní prodej a marketing pro max. 5 uživatelů) - 15$ - Professional (Kompletní CRM pro neomezený počet uživatelů) - 65$ - Enterprise (Customizovatelný CRM pro celý podnik) - 125$ - Unlimited (Na míru optimalizovaný CRM pro celý podnik) - 250$ Všechny uvedené ceny platí při uzavření minimálně ročního kontraktu pro zákazníky z USA viz Salesforce.com [39]. Ceny liší dle lokace zákazníka (např. v EU jsou vyšší). 500 Kč/uživatel/měsíc po dobu používání systému viz Raynet [37] Tradiční model dodávky software, platíme za licenci (neznámo kolik, cena není uvedena na stránkách) a dále za rozšiřující služby (viz MAXprojekt [28]), například: - servis a podpora - 680 Kč / započtená půlhodina - instalace systému na zařízení odběratele - 10 500 Kč - podpora provozu - 12 000 Kč / den - měsíční správa serveru odběratele - 2 500 Kč - školení uživatelů (nejmenší jednotka 1 den) - 1 450 Kč / hodina
Tabulka 2.4: Srovnaní CRM systémů - Platební modely
Hodnocení V poslední tabulce 2.5 jsou uvedeny klady a zápory všech tří systémů. V celkovém hodnocení je na tom nejlépe Salesforce.com. Neznamená to ale, že je doporučen k použití ve všech situacích. Vhodný je pro klienty, kteří ve zvolené verzi využijí všechny jeho funkce. Nemusí být produktivní ve všech případech.
2.2.5
Závěr rešerše
Z úspěchů zmíněných poskytovatelů je patrné, že na kvalitním CRM systému se dá postavit dobrý byznys. V případě poskytování systému formou SaaS je výhodou to, že si klienti mohou aplikaci jednoduše, bezplatně vyzkoušet a na základě toho se rozhodnout zda systém opravdu chtějí. Pro poskytovatele to navíc znamená úsporu časových a finančních nákladů (nemusíme příliš komunikovat s klientem, jezdit za ním a osobně prezentovat demo apod.). Vyvíjený systém, nemůže obsáhnout takové množství funkcionality jako nabízí Salesforce.com. Budeme se soustředit především na implementaci standardních funkcí a ostatní, rozšiřující ponecháme dalšímu vývoji. Při návrhu UI se necháme inspirovat systémem Raynet Cloud CRM, který působí nejlépe. Pokusíme se eliminovat jeho nedostatky a naopak přidat ně24
2.3. Katalog požadavků
Salesforce.com
+
-
Raynet cloud CRM
+
INEX online CRM systém
+ -
Hodnocení Široké spektrum funkcí, možnost customizace stránek. Propracovaná nápověda. Množnost integrace s několika aplikacemi. Klienti pro mobilní zařízení. Minimální náklady na zavedení a provoz ze strany klienta. Cena za uživatele u základní verze. Online demo. Lokalizace do několika jazyků. Drobné nedostatky v UI. Připomínač formou vyskakovacích oken. Vysoká cena za vyšší verze s veškerou funkcionalitou CRM. Omezený počet uživatelů pro nižší tarify. Jednoduché a přehledné UI. Výuková videa. Mobilní klienti. Export dat do formátu iCalendar. REST API. Minimální náklady na zavedení a provoz ze strany klienta. Online demo. Chybí lokalizace. V rozbalovacím hlavním menu nejsou viditelné všechny položky. Chybí funkce správy kampaní. Lokalizace do dvou jazyků. Možnost integrace s účetními a ERP systémy. Chybí podpora pro mobilní klienty. Vysoká cena za licenci, vysoká cena za podporu. Zodpovědnost za provoz a nasazení systému na straně klienta. Pouze globální nápověda. Pro spuštění online dema je nutná interakce s poskytovatelem.
Tabulka 2.5: Srovnaní CRM systémů - Hodnocení
které zajímavé prvky z ostatních aplikací. Na základě návrhu uživatelského rozhraní vybereme vhodné implementační prostředí tak, aby bylo možné splnit požadavky návrhu. Aplikace bude vyvíjena jako SaaS. Platební model bude standardní pro tento typ služeb. Jeho konkrétní podoba je součástí byznys strategie, která není předmětem této práce.
2.3
Katalog požadavků
Požadavky jsou schopnosti a podmínky, které systém a obecněji projekt musí splňovat viz Jacobson [20]. Hlavním cílem analýzy požadavků je nalezení, sdělení a poznamenání toho, co je opravdu potřeba ve formě, která je čitelná jak pro klienta, tak i pro členy vývojového týmu viz Larman [26]. Velmi často se rozlišují dva typy požadavků – funkční a nefunkční viz Arlow [1]. Funkční požadavky určují, jaké chování bude systém nabízet. Nefunkční specifikují vlastnosti nebo omezující podmínky daného systému.
Aktéři systému Seznam aktérů systému a jejich krátký popis byl již uveden v kapitole deklarace záměru 2.1. Chybí uvedení jednoho dosud nezmíněného aktéra – zodpovědná osoba (responsible). Je to jeden ze zaměstnanců klienta, který je zodpovědný za správu uživatelských účtů ostatních svých kolegů, kteří používají CRM aplikaci. 25
2. Úvodní studie Názvy aktérů systému vystupují v popisu funkčních požadavků. Podrobný popis aktérů je součásti modelu případů užití viz kapitola 3.2.1.
2.3.1
Funkční požadavky
U každého požadavku je uvedena číselná hodnota stanovující prioritu řešení požadavku. Požadavek s nejvyšší hodnotou priority označuje důležitou funkcionalitu, která bude do systému implementována v první iteraci realizace. Požadavky s nižšími prioritami budou realizovány postupně v dalších iteracích. Pracuji se čtyřmi stupni priority (0 až 4). F001: Systém bude umožňovat správu účtů (společností, firem) Uživatel bude moct vytvořit nový účet (společnost, firmu). Pro vytvoření nového účtu musí vyplnit jeho název, stav a typ. Volitelně vyplní další informace jako adresu, telefonní kontakt, oblast působení atd. Po vytvoření účtu se uživatel stává jeho vlastníkem. Uživatel bude moct zobrazit seznam všech účtů, které jsou vlastněny klientem, pod kterého uživatel spadá. Tyto účty bude moct filtrovat, řadit a editovat. • Priorita - 4 F002: Systém bude umožňovat správu kontaktů (osob) Uživatel bude moct vytvořit nový kontakt (osobu). Pro vytvoření nového kontaktu musí vyplnit jeho jméno, příjmení a email. Volitelně vyplní další informace jako telefon, pohlaví apod. Zároveň může kontakt navázat na nějakou společnost (účet). Po vytvoření kontaktu se uživatel stává jeho vlastníkem. Uživatel bude moct zobrazit seznam všech kontaktů, které jsou vlastněny klientem, pod kterého uživatel spadá. Tyto kontakty bude moct filtrovat, řadit a editovat. • Priorita - 4 F003: Systém bude umožňovat správu produktů Uživatel bude moct vytvořit nový produkt. Pro vytvoření nového produktu musí vyplnit jeho název, cenu a kódové označení. Volitelně vyplní další informace jako kategorii, popis atd. Po vytvoření produktu se uživatel stává jeho vlastníkem. Uživatel bude moct zobrazit seznam všech produktů, které jsou vlastněny klientem, pod kterého uživatel spadá. Tyto produkty bude moct filtrovat, řadit a editovat. • Priorita - 4 F004: Systém bude umožňovat správu obchodních případů Uživatel bude moct vytvořit nový obchodní případ. Pro vytvoření nového obchodního případu musí vyplnit jeho předmět. Volitelně vyplní další informace jako pravděpodobnost uskutečnění, předpokládanou dobu uzavření, zdroj atd. Může na něj zároveň navázat produkty, které jsou 26
2.3. Katalog požadavků v rámci daného případu předmětem prodeje. Po vytvoření obchodního případu se uživatel stává jeho vlastníkem. Uživatel bude moct zobrazit seznam všech obchodních případů, které jsou vlastněny klientem, pod kterého uživatel spadá. Tyto obchodní případy bude moct filtrovat, řadit a editovat. • Priorita - 4 F005: Systém bude umožňovat správu aktivit Uživatel bude moct vytvořit novou aktivitu. Pro vytvoření nové aktivity musí vyplnit její název, datum jejího konání a její typ (telefonát, schůzka, úkol, událost atd.). Volitelně vyplní další informace jako čas připomenutí, její stav (realizována, naplánována, zrušena) atd. Může na ni zároveň navázat uživatele, kteří se aktivity účastní, případně navázat obchodní entitu (obchodní případ, kontakt, účet, produkt atd.), které se aktivita týká. Po vytvoření aktivity se uživatel stává jejím vlastníkem. Uživatel bude moct zobrazit seznam všech jeho aktivit. Tyto aktivity bude moct filtrovat, řadit a editovat. • Priorita - 3 F006: Systém bude umožňovat správu ceníků Uživatel bude moct vytvořit nový ceník. Pro vytvoření nového ceníku musí vyplnit jeho název. Volitelně na něj naváže produkty a stanoví jejich novou ceníkovou cenu. Po vytvoření ceníků se uživatel stává jeho vlastníkem. Uživatel bude moct zobrazit seznam všech ceníků, které jsou vlastněny klientem, pod kterého uživatel spadá. Tyto ceníky bude moct filtrovat, řadit a editovat. • Priorita - 2 F007: Systém bude umožňovat zobrazení reportů Uživatel bude moct zobrazit reporty. Uživatel specifikuje pro jaké období chce report zobrazit. Systém bude poskytovat report zobrazující objem prodeje uživatelů (počet realizovaných obchodních případů) za určité období ve formátu sloupcového grafu. Systém bude poskytovat report zobrazující úspěšnost prodeje dle různých kritérií (zdroje obchodního případu, jeho kategorie, stavu atd.) ve formátu koláčového diagramu. Systém bude poskytovat report zobrazující vývoj prodeje za zvolené období ve formátu sloupcového grafu. • Priorita - 1 F008: Systém bude umožňovat zobrazení účtu kolegy Uživatel bude moct zobrazit seznam svých kolegů (uživatelů systému, kteří spadají pod stejného klienta) a zobrazit detailní informace o uživateli (jméno, kontakt). • Priorita - 2 27
2. Úvodní studie F009: Systém umožní přidání komentáře k obchodním entitám Uživatel bude moct přidávat komentáře k obchodním entitám (produktům, obchodním případům, aktivitám, účtům, kontaktům a ceníkům). Na komentář může odpovědět jiný uživatel. • Priorita - 3 F010: Systém zobrazí upozornění na blížící se aktivity Systém bude zobrazovat upozornění na naplánované aktivity uživatele (události, úkoly, schůzky atd.) v čase, na který bude stanovena připomínka. Uživatel bude moct zobrazit seznam upozornění na naplánované aktivity a přejít na detailní informace o těchto aktivitách. • Priorita - 3 F011: Systém zobrazí upozornění na změnu vlastníka obchodní entity Systém bude zobrazovat upozornění na změnu vlastnictví obchodní entity (kontaktu, účtu, produktu, obchodního případu atd.) uživateli, který ji vlastnil před tím, než došlo ke změně vlastnictví. Uživatel bude moct zobrazit seznam upozornění na změny vlastnictví a přejít na detailní informace o těchto změnách, kde bude uvedeno, kdo a kdy změnu provedl. • Priorita - 3 F012: Systém zobrazí upozornění na odpovědi ke komentářům Systém bude zobrazovat upozornění na odpovědi ke komentářům, které do systému vložil uživatel k nějaké obchodní entitě (kontaktu, účtu, obchodnímu případu atd.). Uživatel bude moct zobrazit seznam upozornění na odpovědi ke komentářům a přejít na zvolené vlákno komentářů obchodní entity. • Priorita - 3 F015: Systém bude umožňovat správu nástěnky Uživatel bude moct nastavit jaké panely chce zobrazovat na nástěnce. Můžou to být panely zobrazující reporty, seznam aktivit, rychlé volby apod. • Priorita - 2 F021: Systém bude umožňovat správu uživatelského účtu Uživatel bude moct upravovat svůj uživatelský účet. Bude moct editovat své kontaktní údaje nebo heslo pro přístup do systému. • Priorita - 3 F022: Systém bude umožňovat zobrazení nápovědy Uživatel bude moct zobrazit nápovědu k používání aplikace. V systému bude globální nápověda obsahující obecné informace o tom, jak systém používat. U některých prvků rozhraní bude kontextová nápověda. 28
2.3. Katalog požadavků • Priorita - 2 F023: Systém bude umožňovat obnovení zapomenutého hesla Uživatel bude moct obnovit zapomenuté heslo pro přihlášení do systému. Systém vygeneruje nové heslo a odešle ho uživateli na email. • Priorita - 1 F031: Systém bude umožňovat správu uživatelů klienta Zodpovědná osoba bude moct odeslat pozvánku pro vstup do systému novému uživateli (kolegovi) prostřednictvím emailu. Zodpovědná osoba bude moct zobrazit seznam všech uživatelů spadajících do jeho společnosti a bude mít právo zneplatnit uživatelský účet (odepřít uživateli přístup do systému). • Priorita - 3 F051: Systém bude umožňovat správu klientů Manažer bude moct zobrazit seznam všech klientů systému a zodpovědných osob pro tyto klienty. Manažer bude moct změnit kontaktní údaje klienta nebo zodpovědné osoby. • Priorita - 3 F052: Systém bude umožňovat odeslání faktury klientovi Systém bude automaticky odesílat elektronickou verzi faktury na email klienta. Celková částka k uhrazení bude vypočítána jako součin počtu aktivních uživatelů, kteří spadají pod klienta a ceny za měsíční používání CRM aplikace jedním uživatelem. • Priorita - 1 F053: Systém bude umožňovat správu faktur Manažer bude moct zobrazit seznam vystavených faktur a detail zvolené faktury, ve kterém bude moct upravit fakturační údaje. Upravenou fakturu bude moct odeslat v elektronické verzi na email klienta. • Priorita - 1 F061: Systém bude umožňovat správu manažerů Administrátor systému bude moct zobrazit seznam všech manažerů. Bude moct založit nový manažerský účet nebo zneplatnit účet stávajícímu manažerovi. • Priorita - 2 F062: Systém bude umožňovat nastavení ceny za používání CRM Administrátor systému bude moct nastavit cenu za jednoho uživatele za měsíc používání CRM aplikace. • Priorita - 2 29
2. Úvodní studie F071: Systém bude zaznamenávat systémové informace o entitě Každá nově vytvořená entita systému (uživatel, klient, produkt, kontakt apod.) sebou ponese informaci o tom, který uživatel a kdy ji založil. Entita bude rovněž obsahovat informace o poslední změně – uživateli, který ji změnil a čase. • Priorita - 4 F072: Systém bude poskytovat zkušební verzi systému (demo) Návštěvník webu bude moct vyzkoušet demo verzi CRM aplikace. Přihlásí se pod účtem s názvem „demo“, který spadá pod vzorového klienta. Každý den nahraje systém vzorové záznamy navázané na tohoto klienta (produkty, obchodní případy, účty, kontakty atd.). Tímto způsobem bude zajištěno, že si návštěvník bude moct vyzkoušet veškerou funkcionalitu aplikace. • Priorita - 1 F073: Systém bude umožňovat objednání CRM systému Návštěvník webu bude moct objednat CRM aplikaci. Pro objednání bude nutné, aby se nejprve registroval ve webovém rozhraní a vytvořil klientský účet. Po registraci a přihlášení do systému v roli zodpovědné osoby bude moct objednat CRM aplikaci pro zvolený počet uživatelů. Následně pozve uživatele tak, že zadá jejich emailové adresy, na které systém odešle email s pozvánkou a vygenerovaným heslem. • Priorita - 1
2.3.2
Nefunkční požadavky
Grady [18] uvádí způsob kategorizace požadavků zvaný FURPS45 , který využívá i metodika UP46 . Písmeno „F“ v názvu označuje funkční požadavky, ostatní písmena značí kategorie nefunkčních požadavků. Toto členění nefunkčních požadavků je zde z části použito. Systém bude nasazen jako webová aplikace a bude přístupný prakticky jakémukoli uživateli sítě internet. Webové aplikace jsou vystaveny potenciálně neomezenému množství současně pracujících uživatelů. To má dopad na zvýšené nároky na bezpečnost, ovladatelnost, škálovatelnost a dostupnost. Tato skupina pojmů tvoří další kategorie nefunkčních požadavků. Bezpečnost Systém bude standardním způsobem autentizovat uživatele pro vstup do systému a autorizovat jeho přístup k datům. 45 46
30
Functional, Usability, Reliability, Performance, Suppotability Unified Process
2.4. Návrh architektury řešení Škálovatelnost Systém bude flexibilně reagovat na změnu svého zatížení bez nutnosti zásahu lidského faktoru. Dostupnost a spolehlivost Systém bude dostupný v režimu 24/7 (24 hodin denně, 7 dní v týdnu) s minimálními výpadky. Použitelnost Systém bude poskytovat komplexní nápovědu pro jeho používání a u některých prvků i nápovědu kontextovou. Bude vytvořena uživatelská příručka. Systém bude přístupný přes webový prohlížeč. Primárně podporovanými prohlížeči jsou Mozilla Firefox a Google Chrome. Systém bude optimalizován pro minimální rozlišení obrazovky 1280x800. Podpora Systém bude poskytovat podporu pro více jazyků (lokalizaci). Výchozí lokalizací bude angličtina, další podporovanou čeština. Systém bude umožňovat uživateli nastavení a customizovatelnost. Funkcionalita systému bude ověřena jednotkovým testováním. Použitelnost uživatelského rozhraní bude ověřena testováním použitelnosti. Implementace Systém bude nasazen na platformě GAE a vyvinut v jazyce Java. Obchodní a právní aspekty Systém bude poskytován formou SaaS.
2.4
Návrh architektury řešení
Systém bude realizován jako webová aplikace, která bude nasazena v PaaS prostředí, na platformě Google App Engine. Uživatel bude k aplikaci přistupovat přes webový prohlížeč instalovaný na jeho počítači. Konkrétní fyzická architektura navrhovaného systému je včetně diagramu nasazení (viz obrázek 4.5) a obrázku zobrazujícího mechanizmus rozdělení zátěže na GAE popsána v kapitole 4.3.2.
2.5
Analýza rizik
Analýza a řízení rizik je řada kroků, které pomáhají softwarovému týmu odhalit a řídit nejistoty, které mohou v průběhu celého životního cyklu vývoje software nastat viz Pressman [35]. Softwarový projekt může být ohrožen mnoha problémy. Riziko je potenciální problém – může nastat, ale nemusí. Bez ohledu 31
2. Úvodní studie na to zda nastane či nikoli, je dobré jej identifikovat, vyhodnotit ho, určit pravděpodobnost jeho výskytu, odhadnout jeho dopady a vytvořit plán pro situaci, kdyby k danému problému skutečně došlo. Účelem provedení analýzy rizik bylo odhalení problémů, které by mohly nastat a předejití časovým a finančním ztrátám. Pressman [35] uvádí tři obecné kategorie rizik: Projektová rizika (P) ohrožují plán projektu. To znamená, že pokud riziko skutečně nastane, je pravděpodobné, že bude harmonogram projektu ve skluzu a zvýší se náklady. Projektová rizika identifikují potenciální problémy spojené s rozpočtem, harmonogramem, personálem, zdroji, zákazníkem a požadavky a určují jejich dopad na softwarový projekt. Technická rizika (T) ohrožují kvalitu a včasnost dodání softwarového produktu. Pokud nastane technické riziko, může být implementace obtížná nebo zcela nemožná. Technická rizika identifikují potenciální problémy spojené s návrhem, implementací, rozhraními, verifikací a údržbou. Byznys rizika (B) ohrožují uskutečnitelnost vyvíjeného software (projektu i produktu). Byznys neboli obchodní rizika identifikují potenciální problémy spojené s poptávkou po produktu, měnící se podnikovou strategií, schopností prodeje produktu, změnami podpory projektu ze strany vedení podniku a rozpočtovými a personálními ztrátami.
2.5.1
Identifikace rizik
V této kapitole jsou popsána rizika, která byla identifikována u tohoto projektu. U každého rizika je uvedeno jeho označení, kategorie, název a popis. Vyhodnocení rizik je uvedeno v tabulce 2.6 v následující podkapitole 2.5.2. R01-P: Kvalita a dostupnost vývojových nástrojů Zvolím neosvědčený vývojový nástroj, který nesplní mé očekávání nebo nebude splňovat požadavky. Jedná se především o volbu IDE pro implementaci systému, nástrojů CASE pro modelování systému a systému pro správu verzí projektu. Tyto nástroje jsou v dnešní době na podobné úrovni, jejich volba by se neměla ve větší míře projevit na vývoji. – Dopad: zanedbatelný, Pravděpodobnost: 5 % R02-P: Špatně odhadnutá velikost projektu Plánovaná doba vývoje se protáhne kvůli tomu, že špatně odhadu velikost projektu nebo špatně naplánuji vývoj. Jelikož aplikace není primárně určena pro žádného konkrétního zákazníka, nemá toto riziko kritický dopad. V případě prodloužení vývoje není sice nutné hradit žádné penále, prodloužení doby vývoje mě časově a finančně zatíží. – Dopad: marginální, Pravděpodobnost: 30 % 32
2.5. Analýza rizik R03-T: Nepřehledné, nepoutavé, nepoužitelné uživatelské rozhraní Vytvořím uživatelské rozhraní bez předchozího návrhu a otestování. To v konečném důsledku nebude vyhovovat koncovým uživatelům – nebude přehledné, dostatečně intuitivní a poutavé. Tím ztratím nebo si nezískám zákazníky, což může mít až katastrofální dopad na celý projekt. – Dopad: katastrofální, Pravděpodobnost: 25 % R04-B: Nízká poptávka po produktu Produkt budu nabízet špatné skupině zákazníků. Atraktivní zákazníci se o produktu nedozví. Poptávka po produktu bude nízká a produkt nebude rentabilní, přijdu o investice vložené do projektu. Toto riziko má vyšší pravděpodobnost. Nemám potřebné zkušenosti s nabídkou software. Riziko je možné eliminovat outsourcingem v této oblasti, proto není jeho dopad tak velký. – Dopad: marginální, Pravděpodobnost: 35 % R05-B: Špatný marketing a prodej produktu Nebudu schopen vlastními silami prodat produkt. Zákazníci se o produktu nedozví kvůli špatné marketingové strategii a projekt nebude rentabilní. Riziko má velkou pravděpodobnost. Nemám zkušenosti s marketingem a prodejem. Tyto služby ale můžu outsourcovat, proto nemají na projekt takový dopad. – Dopad: marginální, Pravděpodobnost: 40 % R06-T: Škálovatelnost webové aplikace Systém nedokáže pružně reagovat na měnící se počet požadavků, který budou zákazníci a uživatelé aplikace klást. Nezvládne větší zátěž. To povede ke ztrátě zákazníků. Systém ale bude nasazen na cloudovou platformu, která se o škálovatelnost postará. Pravděpodobnost výskytu tohoto rizika je tedy nízká, dopad by ovšem byl kritický. – Dopad: kritický, Pravděpodobnost: 5 % R07-T: Bezpečnost systému Nasadím systém, který nebude dostatečně zabezpečen a dojde k odcizení nebo manipulaci s citlivými podnikovými informacemi některého ze zákazníků. Nebo bude na systém proveden útok, který ho vyřadí z provozu. Toto riziko má katastrofální důsledky – ztráta zákazníků a možné právní spory. Nemá zanedbatelnou pravděpodobnost, musí být řízeno. – Dopad: katastrofální, Pravděpodobnost: 20 % R08-P: Technické schopnosti a zkušenosti Přecením své schopnosti. Mám malé zkušenosti s vývojem na platformě GAE a nebudu schopen vyvinout systém v takové kvalitě jaká je od něj očekávána. Tento problém by měl kritický dopad na vývoj systému. Jeho pravděpodobnost není zanedbatelná. – Dopad: kritický, Pravděpodobnost: 30 % 33
2. Úvodní studie R09-P: Špatné stanovení požadavků na systém Nesprávně určím funkční a nefunkční požadavky, neprovedu jejich analýzu. Špatný odhad požadavků může mít kritický dopad na vývoj systému a celý projekt, který by mohl být v konečném důsledku nepoužitelný. Pokud opomenu nějaký zásadní požadavek, jeho dodatečná implementace může způsobit velký, nákladný zásah do logiky systému. S analýzou požadavků mám zkušenosti. Toto riziko může i přesto nastat. – Dopad: kritický, Pravděpodobnost: 25 % R10-T: Technologie nebo framework nesplní očekávání Technologie nebo framework, který použiji pro vývoj nesplní očekávání a nebudu moci implementovat nějakou funkcionalitu. Budu ji muset nahradit za jinou. Závažnost tohoto rizika se liší dle času kdy nastane. Nastane-li v pokročilé fázi projektu např. těsně před nasazením, má kritické důsledky. Budu volit ověřené technologie. Ty ovšem na GAE nemusejí fungovat, proto není pravděpodobnost zanedbatelná. – Dopad: kritický, Pravděpodobnost: 15 % R11-T: Nasazení neověřeného systému Nasadím systém, který bude vykazovat velké množství chyb a zákazník s ním nebude moci pracovat. To povede ke ztrátě zákazníka. Může mít kritický dopad. Neprovedu-li testování je pravděpodobnost výskytu tohoto problému vysoká. – Dopad: kritický, Pravděpodobnost: 30 % R12-T: Platforma GAE bude vykazovat výkonnostní nedostatky Nasadím systém na platformu GAE, doba jeho odezvy bude nepřiměřená. Zákazník bude dlouho čekat než systém obslouží jeho požadavky a práce se systém bude pro něj ztrátová. Mohlo by vést ke ztrátě zákazníka, což by mělo katastrofální dopad. App Engine garantuje v SLA47 parametry nabízených služeb. Není pravděpodobné, že by vznikl problém v důsledku výkonnostních nedostatků ze strany GAE. – Dopad: katastrofální, Pravděpodobnost: 5 % R13-T: Platforma GAE bude vykazovat technologické nedostatky Některé prvoplánové a ověřené technologie nebudu moci použít (budu muset přejít na jiné) nebo bude jejich použití vyžadovat nestandardní postupy a dojde k prodloužení doby vývoje systému. Prodloužení doby vývoje nemá vysoký vliv na finanční ztráty. Platforma App Engine ale nepodporuje mnoho technologií a tento problém může nastat. – Dopad: marginální, Pravděpodobnost: 20 % R14-B: GAE změní platební podmínky, zvýší se provozní náklady Systém bude závislý na platformě GAE, na které bude provozován. Společnost Google ale může změnit platební podmínky služeb GAE, což 47
34
Service Level Agreement
2.5. Analýza rizik zvýší náklady na provoz systému a sníží můj zisk. Není příliš pravděpodobné a časté aby došlo ke změně platebních podmínek. Dopad na projekt by neměl být velký, závisí na velikosti změny. – Dopad: marginální, Pravděpodobnost: 10 % R15-B: Obtížná rozšiřitelnost systému Navrhnu a implementuji systém tak, že jej nebude možno v budoucnu rozšířit nebo upravit (např. vyvinout mobilního klienta, API nad systémem). Nemožnost nebo komplikovaný způsob rozšíření povede k tomu, že bude rozšíření příliš nákladné nebo zcela nemožné. Neexistence rozšíření se může stát konkurenční nevýhodou. S návrhem systémů mám určité zkušenosti. I tak je pravděpodobné, že nastane nějaký problém s rozšiřitelností. Dopad ovšem není kritický. – Dopad: marginální, Pravděpodobnost: 25 %
2.5.2
Vyhodnocení
Výstupem analýzy rizik je vyhodnocení (viz tabulka 2.6), ve které jsou uvedena všechna známá rizika spojená s tímto projektem, uveden stupeň jejich závažnosti a způsob jejich zmírnění nebo řízení. Kategorie rizika je označena v jeho identifikátoru. Ve sloupci „D“ tabulky 2.6 je uvedeno ohodnocení závažnosti rizika (dopad), ve sloupci „P“ pravděpodobnost toho, jestli riziko nastane a ve sloupci „H“ jeho hodnota vypočítaná jako součin hodnoty dopadu a pravděpodobnosti. Rozlišují se čtyři stupně závažnosti (dopadu) rizika: 1. zanedbatelný 2. marginální 3. kritický 4. katastrofický Rizika jsou seřazena sestupně od toho s nejvyšší hodnotou. Poslední sloupec obsahuje popis opatření, které bude provedeno pro jeho zmírnění, případně eliminaci pokud nastane.
35
2. Úvodní studie Riziko
P [%]
D
H
Opatření
R03-T Nepřehledné, nepoutavé, nepoužitelné uživatelské rozhraní R08-P Technické schopnosti a zkušenosti
25
4
1
30
3
0,9
R11-T Nasazení neověřeného systému R05-B Špatný marketing a prodej produktu R07-T Bezpečnost systému R09-P Špatné stanovení požadavků na systém R04-B Nízká poptávka po produktu R02-P Špatně odhadnutá velikost projektu
30
3
0,9
40
2
0,8
20
4
0,8
25
3
0,75
35
2
0,7
30
2
0,6
R15-B Obtížná rozšiřitelnost systému
25
2
0,5
R10-T Technologie nebo framework nesplní očekávání R13-T Platforma GAE bude vykazovat technologické nedostatky
15
3
0,45
20
2
0,4
R12-T Platforma GAE bude vykazovat výkonnostní nedostatky
5
4
0,2
R14-B GAE změní platební podmínky, zvýší se provozní náklady
10
2
0,2
R06-T Škálovatelnost webové aplikace
5
3
0,15
R01-P Kvalita a dostupnost vývojových nástrojů
5
1
0,05
Provedu návrh uživatelského rozhraní a jeho testování. Na hotové aplikaci provedu testovaní použitelnosti se zástupci cílových skupin. Nastuduji technologie a „best practicies“ z oblasti návrhu a vývoje aplikací v jazyku Java na platformě GAE. Projekt budu konzultovat s externími experty pro tuto oblast vývoje. Implementuji jednotkové testy a provedu další druhy testování systému. Budu konzultovat nebo outsourcovat odborníky z oblasti marketingu a prodeje. Nastuduji a implementuji obecné a doporučené bezpečnostní mechanismy pro platformu GAE. Provedu rešerši předních CRM systémů na trhu, na jejíž základě stanovím požadavky. Provedu analýzu trhu a zacílím marketing na klíčové skupiny zákazníků. Odhadnu pracnost na základě zkušeností z předchozích projektů, na kterých jsem pracoval. Stanovím harmonogram projektu a milníky, ve kterých budu práci prezentovat vedoucímu práce. Nastuduji „best practicies“ z oblasti OOD48 , OOP49 a technologií pro vývoj podobných systému. Navrhnu a implementuji systém podle těchto doporučení tak, aby byl rozšiřitelný. Budu dbát na psaní dokumentace kódu i projektu. Nastuduji technologie a frameworky, které jsou plánovány pro vývoj a ověřím jejich funkčnost na prototypu aplikace. Nastuduji a vyberu technologie, které je možno použít pro vývoj na platformě GAE v jazyku Java. Pokud nějaká technologie nebude použitelná, zvolím adekvátní náhradu a cyklus zopakuji. Budu se držet doporučení pro vývoj na GAE a dle nich systém optimalizuji. Budou-li patrné výkonností nedostatky, přejdu na vyšší, placenou verzi GAE, která má lepší výkonnostní parametry. Tuto situaci ošetřím ve smlouvě o poskytování služeb (SLA) systému CRM, který vyvíjím. Uvedu v ní, že bude možné zvýšit cenu poskytovaných služeb na základě zvýšení cen služeb subdodavatele. Implementuji mechanizmy pro podporu škálovatelnosti aplikace (Memcache apod.), o kterou se stará load balancing na platformě GAE. Zvolím osvědčené nástroje a při výběru IDE uvážím doporučení pro vývoj v jazyku Java na platformě GAE.
Tabulka 2.6: Vyhodnocení analýzy rizik
36
Kapitola
Analýza V první části je rozebrán konceptuální datový model, jeho jednotlivé entity a vztahy mezi nimi. Druhá část je věnována modelu případů užití systému, definici aktérů systému a specifikaci případů užití systému.
3.1
Konceptuální datový model
Konceptuální datový model slouží k vizualizaci konceptů reálného světa v kontextu problémové domény viz Larman [26]. Tyto koncepty jsou reprezentovány formou konceptuálních tříd, které odpovídají reálným prvkům problémové domény, a vztahů, které mezi nimi jsou. Nejedná se o diagramy, které popisují doménovou vrstvu softwarové architektury, softwarové artefakty (komponenty jako např. databáze) nebo softwarové třídy (Java nebo C# třídy – obsahují metody). Může ale sloužit jako inspirace pro návrh softwarových tříd. Konceptuální datový model CRM systému je zobrazen na obrázku 3.1. Základní entitou je „AppUser“, která reprezentuje uživatele systému. Jeho potomky jsou „User“ – pracovník klienta systému a „Manager“ – pracovník CRM systému, který spravuje účty klientů „Client“ a faktury jim vystavené „Invoice“. Stěžejními entitami systému, se kterými pracuje uživatel, jsou obchodní entity, které jsou potomky entity „BusinessEntity“. Jsou to entity „Account“ (účet, společnost, firma, zákazník), „Contact“ (kontakt, osoba), „Product“ (produkt, výrobek, služba), „PriceList“ (ceník produktů), „Activity“ (aktivita) a „BusinessCase“ (obchodní případ, příležitost). Ke všem těmto entitám je možné přidávat komentáře (entita „Comment“). Entita reprezentující připomínku ( „Reminder“), na kterou je uživatel upozorněn, může být trojího typu – „Alarm“ (připomenutí aktivity), „Communication“ (odpověď na komentář) a „Warning“ (změna vlastnictví obchodní entity). Jednotlivé entity, atributy a vztahy mezi entitami jsou popsány níže. Na základě tohoto modelu a zvoleného způsobu ukládání dat na GAE bude navržen fyzický datový model. 37
3
3. Analýza
38 Obrázek 3.1: Konceptuální datový model
3.1. Konceptuální datový model
3.1.1
Entity a jejich atributy
GenericEntity(«generic») obecná entita, která je předkem pro všechny entity systému (tato vazba není uvedena v konceptuálním modelu 3.1) createdDate – čas a den vytvoření entity modifiedDate – čas a den provedení poslední změny entity version – verze entity (inkrementuje se s každou změnou) AppUser obecný uživatel systému, každá osoba, která má vytvořen uživatelský účet, může se přihlásit do systému a pracovat s ním blocked – označuje, zda je uživatelský účet zablokován firstName – křestní jméno email – email language – preferovaný jazyk CRM aplikace lastName – příjmení password – heslo pro přihlášení do systému username – přihlašovací jméno do CRM systému User reprezentuje aktéra „Uživatel“ viz model aktérů 3.2.1 dashboardItems – nastavení zobrazovaných panelů na nástěnce lastLoginDate – čas a den posledního přihlášení aktéra „Uživatel“ CrmService nastavení CRM služeb monthPrice – cena za měsíční používání CRM služeb jedním uživatelem currency – měna ceny BusinessEntity obchodní entita, předek pro entity obchodního charakteru, které můžou uživatelé komentovat, vázat na ně své aktivity apod. note – poznámka k obchodní entitě Account účet representuje firmu nebo společnost, se kterou obchoduje a má v evidenci klient CRM systému companyId – identifikátor, který používá klient k identifikaci společnosti email – email společnosti employeesCount – počet zaměstnanců společnosti name – název společnosti phone – telefonní kontakt revenue – roční příjem společnosti web – webové sídlo společnosti Contact kontakt na osobu, kterou eviduje klient u nějaké své společnosti email – email na osobu firstName – křestní jméno lastName – příjmení language – jazyk preferovaný pro komunikaci phone – telefonní kontakt web – webové stránky osoby 39
3. Analýza Product produkt, který má klient v prodejním katalogu a prodává ho enabled – označení toho, zda je produkt momentálně určen k prodeji code – kódové označení produktu currency – měna ceny description – popis produktu name – název produktu price – cena produktu PriceList ceník má klient vytvořen pro skupinu produktů (obsahuje produkty a jejich ceníkové ceny) enabled – – označení toho, zda je ceník momentálně určen k nabídce name – – název ceníku Activity aktivita je událost, schůzka nebo úkol, který má uživatel naplánován dateFrom – – čas začátku aktivity dateTo – – čas konce aktivity name – – název aktivity BusinessCase obchodní případ (nebo příležitost), který klient uzavírá s nějakou společností, kterou v systému eviduje jako svého zákazníka. Může na sebe mít navázány produkty, které jsou předmětem prodeje closedDate – datum uzavření obchodního případu (zaplacen) confirmedDate – datum potvrzení (schválení) prodeje obchodního případu (čeká se na platbu od zákazníka) estimatedCloseDate – předpokládaná doba uzavření o. p. probability – pravděpodobnost uzavření o. p. subject – název o. p., předmět prodeje finalPrice – koncová cena o. p. costsValue – odhadované náklady klienta na realizaci o. p. Reminder připomínka, která uživatele ve stanovený čas upozorňují na naplánovanou aktivitu, změnu v záznamech nebo odpověď na jeho komentář active – označení toho, zda již bylo upozorněno na připomínku remindTime – čas pro upozornění na připomínku Alarm připomínka typu alarm, která slouží k upozornění na naplánovanou aktivitu Warning připomínka typu varování, která slouží k upozornění na změnu v záznamu obchodní entity (změnu vlastnictví obchodní entity, kterou vlastnil uživatel) Communication připomínka typu komunikace, která slouží k upozornění na odpověď na komentář uživatele Comment komentář, který vložil uživatel k nějaké obchodní entitě nebo jako odpověď na jiný komentář date – datum vložení komentáře text – text komentáře 40
3.1. Konceptuální datový model Address poštovní adresa subjektu city – město country – stát, země houseNo – číslo popisné street – ulice zipCode – poštovní směrovací číslo WorksInCompany(«asociační třída») vztah mezi kontaktem (osobou) a účtem (společností), který definuje zaměstnaneckou pozici osoby ve společnosti position – pozice osoby ve společnosti primary – označení primárního zaměstnání osoby ve společnosti PriceListItem(«asociační třída») vztah mezi ceníkem a produktem, který vyjadřuje zahrnutí produktu do ceníku a stanovení jeho ceníkové ceny listPrice – ceníková cena produktu currency – měna ceny ProductItem(«asociační třída») vztah mezi produktem a obchodním případem, který vyjadřuje zahrnutí produktu na seznam objednaných produktů v rámci obchodního případu a stanovení jeho prodejní ceny, slevy, názvu a množství discount – sleva z prodejní ceny produktu v o. p. name – název produktu v o. p. quantity – počet kusů produktu na objednávce o. p. salesPrice – prodejní cena produktu v o. p. Client klient je společnost, která objednala CRM systém. Několik pracovníků klienta má uživatelský účet a používá CRM systém. Tyto služby jsou klientovi měsíčně fakturovány. Na klienta se vážou uživatelé a kategorie, které si vytvořil companyId – identifikace klienta companyName – název klienta email – email klienta maxUsers – limit pro počet uživatelských účtů phone – telefonní kontakt na klienta trialEndDate – den, kdy vyprší zkušební doba web – webové sídlo klienta Manager manažer CRM systému starající se o klienty a spravující jejich účty Invoice faktura vystavená klientovi za užívání systému invoiceDate – datum vystavení faktury invoiceNumber – číslo faktury payDate – datum splatnosti faktury totalAmount – celková částka faktury currency – měna celkové částky 41
3. Analýza InvoiceItem položka faktury price – cena položky comment – komentář k položce discount – sleva ceny položky quantity – množství currency – měna ceny položky name – název položky unit – jednotka položky IndustryField oblast působení definovaná klientem name – název oblasti působení ContactCategory kategorie kontaktů definované klientem name – název kategorie kontaktů ProductCategory kategorie produktů definované klientem name – název kategorie produktů BusinessCaseSource zdroj získání obchodního příp. definovaný klientem name – název zdroje získání o. p.
3.1.2
Vztahy mezi entitami
dědičnost (GenericEntity, *) – Každá entita dědí od obecné entity (GenericEntity). createdBy (GenericEntity, AppUser) [M:1] – Uživatel aplikace (AppUser) může vytvořit několik obecných entit (GenericEntity). Obecná entita je vytvořena právě jedním uživatelem. lastModifiedBy (GenericEntity, AppUser) [M:0..1] – Uživatel aplikace (AppUser) může být posledním upravujícím uživatelem několika obecných entit (GenericEntity). Obecná entita může být naposledy upravena nejvýše jedním uživatelem. hasReminders (User, Reminder) [kompozice 1:M] – Uživatel (User) vlastní několik připomínek (Reminder), na které má být upozorněn. Připomínka je vlastněna právě jedním uživatelem. hasComments (BusinessEntity, Comment) [kompozice 1:M] – Obchodní entita (BusinessEntity) může být opatřena několika komentáři (Comment). Komentář je napsán k právě jedné obchodní entitě. ownedBy (BusinessEntity, User) [agregace M:1] – Obchodní entitu (BusinessEntity) vlastní právě jeden uživatel (User). Uživatel může vlastnit několik obchodních entit. hasIndustry (Account, IndustryField) [M:0..1] – Společnost (Accout) má nejvýše jednu oblast působení (IndustryField). Oblast působení může být společná pro několik různých společností. 42
3.1. Konceptuální datový model hasState (Account, AccountState [M:1] – Společnost (Accout) se nachází v právě jednom stavu (AccountState). Stav společnosti (aktuální, potenciální, nezajímavý) může být společný pro několik různých společností. hasType (Account, AccountType) [M:1] – Společnost (Accout) je právě jednoho typu (AccountType). Typ společnosti (konkurence, zákazník, partner) může být společný pro několik různých společností. hasShippingAddress (Account, Address) [kompozice 1:0..1] – Společnost (Accout) může mít nejvýše jednu doručovací adresu (Address). Adresa patří právě jedné společnosti. hasBillingAddress (Account, Address) [kompozice 1:0..1] – Společnost (Accout) může mít nejvýše jednu fakturační adresu (Address). Adresa patří právě jedné společnosti. hasGender (Contact, GenderType) [M:0..1] – Osoba (Contact) může mít uvedeno pohlaví (GenderType). Stejného pohlaví (muž, žena) může být několik osob. inCategory (Contact, ContactCategory) [M:0..1] – Osoba (Contact) může být zařazena nejvýše v jedné kategorii osob (ContactCategory). V jedné kategorii osob může být zařazeno několik osob. inCategory (Product, ProductCategory) [M:0..1] – Produkt (Product) může být zařazen nejvýše v jedné kategorii produktů (ProductCategory). V jedné kategorii produktů může být zařazeno několik produktů. participates (Activity, User) [M:N] – Uživatel (User) se může účastnit několika aktivit (Activity). Aktivita může být naplánována pro několik uživatelů. hasState (Activity, ActivityState) [M:0..1] – Aktivita (Activity) může nacházet nejvýše jednom stavu (ActivityState). Stav aktivity (naplánována, uskutečněna, zrušena) může být společný pro několik různých aktivit. hasType (Activity, ActivityType) [M:0..1] – Aktivita (Activity) může mít nejvýše jeden typ (ActivityType). Typ (úkol, událost, telefonát, email, schůzka) může být společný pro několik různých aktivit. relatedTo (Activity, BusinessEntity) [M:0..1] – Aktivita (Activity) může být navázána na nejvýše jednu obchodní entitu (BusinessEntity). Obchodní entita může být navázána na několik aktivit. participates (Activity, Contact) [M:N] – Aktivity (Activity) se může účastnit několik osob (Contact). Osoby se mohou účastnit několika aktivit. hasState (BusinessCase, BusinessCaseState) [M:0..1] – Obchodní případ (BusinessCase) se může nacházet nejvýše v jednom stavu (BusinessCaseState). Stav obchodního případu (v jednání, potvrzen, výhra, prohra) může být společný pro několik různých obchodních případů. 43
3. Analýza hasSource (BusinessCase, BusinessCaseSource) [M:0..1] – Obchodní případ (BusinessCase) může mít nejvýše jeden zdroj původu (BusinessCaseSource). Zdroj původu obchodního případu může být společný pro několik různých obchodních případů. offeredFor (BusinessCase, Account) [M:1] – Obchodní případ (BusinessCase) je nabízen a uzavírán pro právě jednu společnost (Account). Se společností může být uzavřeno několik obchodních případů. contractedWith (BusinessCase, Contact) [M:0..1] – Obchodní případ (BusinessCase) může být sjednán nejvýše s jednou osobou (Contact). Osoba může sjednat několik obchodních případů. remindedBy (Alarm, Activity) [M:1] – Alarm upozorňuje na právě jednu aktivitu (Activity). Na jednu aktivitu může být upozorněno několika alarmy (pro každého uživatele účastnícího se aktivity). warnsEntity (Warning, BusinessEntity) [M:1] – Varování (Warning) upozorňuje právě na jednu obchodní entitu (BusinessEntity), která byla změněna. Na jednu obchodní entitu může upozornit několik varování. remindedBy (Communication, Comment) [M:1] – Připomínka na komunikaci (Communication) upozorňuje na právě jeden komentář. Na jeden komentář může upozornit několik připomínek na komunikaci. repliesTo (Comment, Comment) [kompozice 1:M] – Ke komentáři (Comment) může být vloženo několik odpovědí (Comment). Odpověď je vložena na právě jeden komentář. sendsComment (Comment, User) [M:1] – Uživatel (User) může vložit několik komentářů (Comment). Komentář je vložen právě jedním uživatelem. employs (Contact, WorksInCompany, Account) [1:M, N:1] – Jedna osoba (Contact) může mít několik pracovních vztahů (WorksInCompany), pracovní vztah se váže na právě jednu osobu a na právě jednu společnost (Account). Společnost může mít uzavřeno několik pracovních vztahů. hasProducts (Product, PriceListItem, PriceList) [1:M, N:1] – V jednom ceníku (PriceList) může figurovat několik ceníkových položek (PriceListItem), ceníková položka se váže na právě jeden ceník a na právě jeden produkt (Product). Produkt může figurovat v několika cenících. sellsProducts (Product, ProductItem, BusinessCase) [1:M, N:1] – V rámci jednoho obchodního případu (BusinessCase) může být nabízeno několik prodejních položek (ProductItem), prodejní položka se váže na právě jeden obchodní případ a na právě jeden produkt (Product). Produkt může figurovat v několika obchodních případech. 44
3.1. Konceptuální datový model hasEmployees (Client, User) [kompozice 1:M] – Uživatel (User) je pracovníkem právě jednoho klienta (Client). Klient zaměstnává několik pracovníků, kteří pracují se systémem. responsibleFor (Client, User) [0..1:1] – Klient (Client) má právě jednu zodpovědnou osobu (User), která je uživatelem systému. Uživatel může být zodpovědnou osobou pro nejvýše jednoho klienta. hasType (Client, ClientAccountType) [M:1] – Účet klienta (Client) se nachází právě v jednom stavu (ClientAccountType). Stav klientského účtu (aktivován, trial, k aktivaci, deaktivován) může být společný pro několik různých klientů. issuedFor (Client, Invoice) [1:M] – Pro klienta (Client) může být vystaveno několik faktur (Invoice). Každá faktura je vystavena pro právě jednoho klienta. hasAddress (Client, Address) [kompozice 1:1] – Klient (Client) má uvedenu právě jednu adresu (Address). Adresa patří právě jednomu klientovi. hasIndrustryFields (Client, IndustryField) [kompozice 1:M] – Klient (Client) má nadefinováno několik oblastí působení (IndustryField). Oblast působení je definována právě jedním klientem. businessCaseSources (Client, BusinessCaseSource) [kompozice 1:M] – Klient (Client) má nadefinováno několik zdrojů obchodních případů (BusinessCaseSource). Zdroj obchodního případu je definován právě jedním klientem. hasContactCategories (Client, ContactCategory) [kompozice 1:M] – Klient (Client) má nadefinováno několik kategorií kontaktů (ContactCategory). Kategorie kontaktů je definována právě jedním klientem. hasProductCategories (Client, ProductCategory) [kompozice 1:M] – Klient (Client) má nadefinováno několik kategorií produktů (ProductCategory). Kategorie produktů je definována právě jedním klientem. managedBy (Manager, Client) [1:M] – Manažer CRM systému (Manager) je správcem několika klientských účtů (Client). Klientský účet je spravován právě jedním manažerem. hasState (Invoice, InvoiceState) [M:1] – Faktura (Invoice) se nachází v právě jednom stavu (InvoiceState). Stav faktury (nezaplacená, zaplacená) může být společný pro několik různých faktur. hasItems (Invoice, InvoiceItem) [kompozice 1:1..M] – Faktura (Invoice) je vystavena na jednu a více položek (InvoiceItem). Fakturační položka je uvedena na právě jedné faktuře. 45
3. Analýza
3.2
Model případů užití
Model případů užití obsahuje množinou scénářů, které určují typické použití systému uživateli viz Larman [26]. Vedle textových dokumentů může zahrnovat i diagram případů užití v UML, který zobrazuje jména případů užití, aktéry a vztahy mezi nimi. Případ užití je textovým dokumentem, ve kterém je zachycena interakce uživatele a systému. Existují různé formáty, úrovně formality a šablony pro zápis případu užití. Zde je použit plně specifikovaný formát a šablona (viz tabulka B.1), která byla vytvořena na základě široce rozšířené šablony Alistara Cockburna [9]. Způsob hledání, modelování a popisu případů užití vychází z Larmana [26] a Cockburna [9]. Generalizace případů užití vychází z Arlowa a Neustadta [1]. V následujících podkapitolách jsou zobrazeny všechny diagramy případů užití systému. Většina případů užití je podrobně popsána ve scénářích.
Obrázek 3.2: UC model - Aktéři systému
3.2.1
Model aktérů systému
Aktér je jakýkoli subjekt mající nějaké chování včetně systému samotného, který může volat služby jiných systémů viz Larman [26]. Primární a podpůrní aktéři se vyskytují v jednotlivých akcích scénářů případů užití. Aktéři jsou role vyjadřující nejenom osoby, ale i organizace, software a stroje. Na diagramu 3.2 je znázorněn model primárních aktérů systému. Zobrazuje aktéry CRM systému a vztahy mezi nimi. Vztahy jsou vysvětleny přímo u popisu jednotlivých aktérů. V popisu aktérů jsou zahrnuty i zainteresované osoby (podpůrní aktéři). System (Systém) reprezentuje CRM systém. Figuruje jako primární aktér v některých případech užití. Ve stanovený moment spouští určité akce. 46
3.2. Model případů užití AppUser (Obecný uživatel) je obecný uživatel CRM systému (abstraktní aktér), který má vytvořen uživatelský účet, může se přihlásit do CRM systému a účet upravovat. Admin (Administrátor) je administrátorem CRM systému. Má na starosti správu CRM systému a účtů manažerů. Dědí od obecného uživatele všechny role a relace k případům užití. Manager (Manažer) je manažerem CRM systému. Stará se o klienty CRM systému, kontaktuje je, spravuje jejich účty a má možnost editovat jejich faktury. Dědí od obecného uživatele všechny role a relace k případům užití. Visitor (Návštěvník) je návštěvníkem webové prezentace CRM systému a potenciální klientem. CRM systém může vyzkoušet online demo aplikací. Může se registrovat a založit tak nového klienta. Může CRM systém objednat. Automaticky se pak stává zodpovědnou osobou pro nového klienta. Responsible (Zodpovědná osoba) je zaměstnancem klientské společnosti. Zodpovídá za správu uživatelských účtů klienta. Může přidávat nové účty nebo zneplatnit stávající účty. Uživatel, kterému byl zneplatněn účet, nemůže s CRM systémem pracovat. Dědí od uživatele všechny role a relace k případům užití. Klient je zainteresovanou osobou (nepoužívá systém), která reprezentuje klientskou společnost, firmu, organizaci nebo osobu, které je dodáván CRM systém a jsou odesílány faktury za jeho používaní. User (Uživatel) je zaměstnancem klientské společnosti. V systému může zobrazovat a spravovat účty (společnosti), kontakty (osoby), produkty, ceníky, obchodní případy, aktivity apod. Dědí od obecného uživatele všechny role a relace k případům užití.
3.2.2
UC1: CRM Common
Tato část obsahuje popis případů užití, které může vykonávat obecný uživatel systému (pracovník CRM systému nebo uživatel). Skupina případů užití pokrývá obecné operace CRM systému – přihlášení do systému, odhlášení, správu uživatelského účtu apod. Je zobrazena na diagramu případů užití 3.3. 47
3. Analýza
Obrázek 3.3: UC model - UC1: CRM Common Případ užití - UC101: Log in Context of Use: Uživatel chce použít CRM systém a musí se přihlásit. Scope: CRM systém Level: Cíl uživatele Primary actor: Obecný uživatel (AppUser) Stakeholders and Interests: – Obecný uživatel: Chce používat CRM systém. Preconditions: – Success End: Obecný uživatel je přihlášen do CRM systému a může ho používat. Main success scenario: 1. Obecný uživatel chce použít CRM systém. 2. Systém zobrazí formulář pro přihlášení do systému (přihlašovací jméno a heslo). 3. Obecný uživatel zadá přihlašovací údaje (uživatelské jméno a heslo) a zvolí přihlášení do systému. 4. Systém autentizuje uživatele INCLUDE: UC106: Authenticate. 5. Systém zobrazí výchozí obrazovku CRM systému. Alternative flows: 4a. Uživatel nebyl autentizován (špatné přihlašovací údaje). 1. Systém zobrazí uživateli chybou hlášku a nabídne mu možnost obnovy zapomenutých přihlašovacích údajů. 2. Uživatel pokračuje krokem 2 hlavního scénáře. 2a. Uživatel zvolí obnovu přihlašovacích údajů INCUDE: UC105: Reset forgotten login information. Special Requirements: Uživatel přistupuje k systému přes webový prohlížeč. Frequency of Occurrence: Často – kdykoli chce kterýkoli uživatel spustit CRM systém.
48
3.2. Model případů užití Případ užití - UC102: Log out Context of Use: Obecný uživatel je přihlášen do CRM systému a chce se odhlásit. Scope: CRM systém Level: Cíl uživatele Primary actor: Obecný uživatel (AppUser) Stakeholders and Interests: – Obecný uživatel: Chce bezpečně ukončit práci s CRM systémem. Preconditions: Uživatel je autentizován a přihlášen. Success End: Obecný uživatel je odhlášen z CRM systému. Main success scenario: 1. Obecný uživatel chce ukončit práci s CRM systémem. 2. Obecný uživatel vyvolá akci pro odhlášení. 3. Systém odhlásí uživatele ze systému. 4. Systém zobrazí obrazovku s informací o úspěšném odhlášení. Alternative flows: – Frequency of Occurrence: Často – kdykoli se chce kterýkoli uživatel odhlásit ze systému.
Případ užití - UC103: Manage user profile Context of Use: Obecný uživatel chce upravit svůj uživatelský účet. Scope: CRM systém Level: Cíl uživatele Primary actor: Obecný uživatel (AppUser) Stakeholders and Interests: – Obecný uživatel: Chce aktualizovat záznamy svého uživatelského účtu. – Ostatní uživatelé systému: Chtějí znát aktuální informace o uživateli. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatelský účet obecného uživatele je upraven. Main success scenario: 1. Obecný uživatel chce upravit svůj uživatelský účet. 2. Obecný uživatel zobrazí detail svého uživatelského účtu. 3. Systém zobrazí informace o uživatelském účtu – jméno uživatele, příjmení, email, přihlašovací jméno a jazyk. Vše kromě přihlašovacího jména může uživatel editovat. Systém zobrazí možnost změny přihlašovacího hesla. 4. Obecný uživatel upraví nějaký záznam (jméno, příjmení, email nebo jazyk). 5. Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Obecný uživatel opakuje krok 4 do té doby, než provede všechny požadované změny. 6. Obecný uživatel zvolí akci pro uložení změn. 7. Systém zkontroluje validitu záznamů a uloží změny do systému. Alternative flows: *a. Kdykoli se může uživatel odhlásit ze systému: 1. Uživatel zvolí odhlášení ze systému. 2. IF odhlášení po kroku 4 z hlavního scénáře THEN systém pokračuje krokem *b. 3. Systém odhlásí uživatele INCLUDE: UC102: Log out. *b. Uživatel chce opustit obrazovku. 1. IF uživatel se snaží opustit obrazovku po kroku 4 z hlavního scénáře THEN systém upozorní uživatele, že se pokouší opustit obrazovku a neuložil provedené změny. 2. Uživatel pokračuje krokem 6 hlavního scénáře. 2a. Uživatel nechce změny uložit, ignoruje upozornění.
49
3. Analýza 3. Systém přejde na jinou obrazovku. 4a. Obecný uživatel zvolí změnu přihlašovacího hesla. 1. Systém zobrazí formulář pro změnu hesla (staré heslo, nové heslo, potvrzení nového hesla). 2. Uživatel vyplní formulář pro změnu hesla. 3. Uživatel zvolí akci pro potvrzení změny hesla. 3a. Uživatel zvolí akci pro zrušení změny hesla. 1. Systém pokračuje krokem 3 z hlavního scénáře. 4. Systém ověří správnost starého hesla, splnění bezpečnostní politiky pro nové heslo a ověří shodnost nového hesla s jeho potvrzením. 4a. Uživatel zadal nesprávné staré heslo, jeho nové heslo nesplňuje bezpečnostní požadavky nebo se nové heslo neshoduje s jeho potvrzením. 1. Systém upozorní uživatele na problém, který nastal. 2. Uživatel pokračuje krokem 4a. 5. Systém uloží nové heslo. 7a. Uživatel zadal nevalidní data. 1. Systém upozorní na nevalidní data, která byla zadána uživatelem. 2. Uživatel pokračuje krokem 4 hlavního scénáře. Frequency of Occurrence: Málo – uživatel upravuje svůj profil velmi zřídka.
Případ užití - UC105: Reset forgotten login information Context of Use: Uživatel se nemůže přihlásit do systému, chce změnit přihlašovací údaje. Scope: CRM systém Level: Cíl uživatele Primary actor: Obecný uživatel (AppUser) Stakeholders and Interests: – Obecný uživatel: Zapomněl své přihlašovací údaje, potřebuje je změnit a přihlásit se do systému pomocí nových. Preconditions: – Success End: Obecný uživatel si změnil přihlašovací údaje. Main success scenario: 1. Obecný uživatel chce změnit přihlašovací údaje do systému. 2. Systém zobrazí formulář pro obnovu přihlašovacích údajů (email, přihlašovací jméno). 3. Obecný uživatel zadá email, na který mu má být odesláno nové heslo a zvolí akci obnovu přihlašovacích údajů. 4. Systém vyhledá uživatelský účet se zadaným emailem, vygeneruje pro něj nové heslo a heslo uloží. 5. Systém odešle na email uživatele přihlašovací údaje do systému. 6. Systém informuje uživatele, že mu byly odeslány přihlašovací údaje na email. Alternative flows: 3a. Uživatel chce obnovit heslo zadáním přihlašovacího jména. 1. Uživatel zadá přihlašovací jméno a zvolí akci obnovu přihlašovacích údajů.. 2. Systém vyhledá uživatele se zadaným přihlašovacím jménem, vygeneruje pro něj nové heslo a heslo uloží. 2a. Přihlašovací jméno, které uživatel zadal, systém nenalezl. 1. Systém upozorní uživatele, že nenalezl uživatele s daným přihlašovacím jménem. 2. Uživatel pokračuje krokem 2 z hlavního scénáře. 3. Systém odešle na email uživatele nové heslo k přihlášení do systému. 4. Systém informuje uživatele, že mu bylo odesláno přihlašovací heslo na email (zobrazí pouze část emailové adresy). 4a. Uživatelský účet, který má email odpovídající tomu, jež zadal uživatel, nenalezen.
50
3.2. Model případů užití 1. Systém upozorní uživatele, že nenalezl uživatele s daným emailem. 2. Uživatel pokračuje krokem 2 z hlavního scénáře. Frequency of Occurrence: Málo – uživatel obnovuje přihlašovací údaje velmi zřídka.
Případ užití - UC106: Authenticate Context of Use: Systém obdržel přihlašovací údaje uživatele a autentizuje podle nich uživatele. Scope: CRM systém Level: Funkce Primary actor: Systém Stakeholders and Interests: – Obecný uživatel: Chce se přihlásit do CRM systému z nějakého zařízení. Preconditions: – Success End: Úspěšná autentizace do systému. Main success scenario: 1. Systém chce autentizovat uživatele. 2. Systém vyhledá uživatele podle přihlašovacího jména. 3. Systém ověří, zda přihlašovací heslo odpovídá tomu, které má nastaveno uživatel na svém účtu. 4. Systém informuje o úspěšném pokusu o přihlášení. Alternative flows: 2a. Uživatel nebyl nalezen. 1. Systém vrátí chybu při pokusu o autentizaci. 3a. Hesla si neodpovídají. 1. Systém vrátí chybu při pokusu o autentizaci. Frequency of Occurrence: Často – kdykoli chce kterýkoli uživatel spustit CRM systém.
Případ užití - UC104: Generate sample records for CRM demo Context of Use: Systém ve stanovený čas spustí úlohu, která nahraje vzorová data do demo instance CRM systému. Scope: CRM systém Level: Funkce Primary actor: Systém Stakeholders and Interests: – Návštěvník: Chce si prohlédnout a vyzkoušet demo aplikaci, která se tváří jako skutečná aplikace v níž jsou nahrána data, se kterými může manipulovat. – Poskytovatel CRM systému: Chce získat nové zákazníky tím, že jim umožní vyzkoušení funkční CRM aplikace, ve které jsou vzorová data. Preconditions: – Success End: Vzorová data jsou úspěšně vložena do demo instance. Trigger: Systém spouští scénář jedenkrát denně ve 4:00. Main success scenario: 1. Systém chce nahrát vzorová data do systému. 2. Systém nahraje vzorová data data do demo instance. 3. Systém informuje administrátora CRM systému o úspěšném nahrání vzorových dat odesláním zprávy na jeho email. Alternative flows:
51
3. Analýza 2a. Při nahrávání se vyskytne chyba. 1. Systém odešle zprávu o neúspěšném nahrání vzorových dat administrátorovi a popíše v ní chybu, která se vyskytla. Frequency of Occurrence: Málo – jedenkrát denně.
3.2.3
UC2: Web presentation
Tato část obsahuje popis případů užití, které může spustit návštěvník, který se pohybuje ve webové prezentaci CRM systému – vyzkoušení CRM aplikace, registrace do systému a jeho objednání. Skupina případů užití je zobrazena na diagramu případů užití 3.4.
Obrázek 3.4: UC model - UC2: Web presentation Případ užití - UC201: Try CRM demo Context of Use: Návštěvník webové prezentace chce vyzkoušet CRM aplikaci. Scope: Webová prezentace Level: Cíl uživatele Primary actor: Návštěvník Stakeholders and Interests: – Návštěvník: Chce si prohlédnout a vyzkoušet demo CRM aplikace. – Poskytovatel CRM systému: Chce získat nové zákazníky tím, že jim umožní vyzkoušení funkční CRM aplikace. Preconditions: – Success End: Návštěvník si vyzkoušel demo CRM aplikace. Main success scenario: 1. Návštěvník chce vyzkoušet demo CRM aplikace. 2. Návštěvník spustí akci pro vyzkoušení demo CRM aplikace. 3. Systém zobrazí předvyplněný formulář přihlášení do systému (zadáno je přihlašovací jméno a heslo). 4. Návštěvník se přihlásí do demo CRM aplikace.
52
3.2. Model případů užití 5. Systém zvolí náhodného uživatele demo CRM aplikace a přihlásí návštěvníka do aplikace pod jeho účtem. 6. Systém zobrazí úvodní obrazovku CRM aplikace. Návštěvník pracuje se systémem v roli uživatel. 7. Návštěvník se odhlásí ze systému INCLUDE UC102: Log out. Alternative flows: – Frequency of Occurrence: Málo – frekvence závisí na počtu návštěvníků webové prezentace.
Případ užití - UC202: Order CRM Context of Use: Návštěvník webové prezentace chce objednat CRM aplikaci. Scope: Webová prezentace Level: Cíl uživatele Primary actor: Návštěvník, Zodpovědná osoba Stakeholders and Interests: – Návštěvník: Chce objednat CRM aplikaci. – Poskytovatel CRM systému: Chce získat nového zákazníka. Preconditions: – Success End: Návštěvník si objednal CRM aplikaci. Main success scenario: 1. Návštěvník chce objednat CRM aplikaci. 2. Návštěvník spustí akci pro objednání CRM aplikace. 3. Systém zobrazí formulář pro objednání CRM aplikace (počet uživatelských účtů). 4. Návštěvník vyplní formulář a potvrdí objednávku. 5. Systém vyzve uživatele k přihlášení do systému a nabídne i možnost pro zaregistrování se jako nového klienta. 6. Návštěvník zvolí přihlášení do systému INCLUDE UC101: Log in. Návštěvník se přihlásil v roli zodpovědná osoba. 7. Systém rekapituluje objednávku a dotáže se, zda chce zodpovědná osoba potvrdit objednání CRM aplikace. 8. Zodpovědná osoba potvrdí objednávku. 9. Systém nastaví účet klienta (limit počtu uživatelů) podle objednávky a aktivuje pro něj CRM aplikaci (typ účtu „aktivní“). 10. Systém informuje zodpovědnou osobu u úspěšném objednání CRM aplikace. Alternative flows: 4a. Návštěvník chce zrušit objednání CRM systému. 1. Systém zruší proces objednávky. 5a. Návštěvník se chce zaregistrovat jako nový klient. 1. Návštěvník zvolí registraci do systému INCLUDE UC203: Register as a new client. 2. IF návštěvník není přihlášen THEN systém vyzve návštěvníka pro přihlášení do systému INCLUDE UC101: Log in. 3. Systém pokračuje krokem 7 z hlavního scénáře. 6a. Návštěvník se přihlásil do systému v roli uživatel. 1. Systém upozorní uživatele, že není oprávněn pro objednání CRM aplikace. 2. Systém zruší proces objednávky. 6b. Návštěvník se nepřihlásil do systému. 1. Návštěvník pokračuje krokem 5 z hlavního scénáře. 8a. Zodpovědná osoba zruší objednávku. 1. Zodpovědná osoba zvolí akci pro zrušení objednávky.
53
3. Analýza 2. Systém zruší proces objednávky. 8b. Zodpovědná osoba se odhlásila ze systému. 1. Systém zruší proces objednávky. Frequency of Occurrence: Málo – nový klient objednává CRM aplikaci zřídka.
Případ užití - UC203: Register as a new client Context of Use: Návštěvník webové prezentace chce zaregistrovat svoji společnost do systému. Scope: Webová prezentace Level: Cíl uživatele Primary actor: Návštěvník Stakeholders and Interests: – Návštěvník: Chce registrovat svou společnost do systému. Vytvoří se klientský účet a návštěvník, který provádí registraci se stane zodpovědnou osobou za klientskou společnost. – Poskytovatel CRM systému: Chce získat nové zákazníky. Preconditions: – Success End: Návštěvník registroval svoji společnost do systému a je její zodpovědnou osobou. Main success scenario: 1. Návštěvník chce zaregistrovat svoji společnost. 2. Návštěvník spustí akci pro registraci do systému. 3. Systém zobrazí registrační formulář (název společnosti, email, telefonní kontakt, web a jméno návštěvníka, příjmení, email, přihlašovací údaje). 4. Návštěvník vyplní registrační formulář a potvrdí registraci. 5. Systém zkontroluje validitu zadaných údajů, registruje nového klienta na základě dat z formuláře (nastaví typ účtu na „k aktivaci“), vytvoří nový uživatelský účet pro návštěvníka a nastaví mu roli zodpovědná osoba. 6. Systém odešle zprávu o registraci na email zodpovědné osoby a vyzve zodpovědnou osobu k dokončení registrace čtením zprávy v emailu. Návštěvník přečte email a vyvolá akci pro aktivaci účtu. 7. Systém aktivuje účet klienta, nastaví jeho typ na „trial“, limit počtu uživatelů na čtyři a nastaví třicetidenní limit na vyzkoušení CRM aplikace. 8. Systém odešle zprávu o úspěšné aktivaci na email zodpovědné osoby. 9. Systém informuje návštěvníka o úspěšném dokončení registrace a nabídne mu možnost přihlášení do CRM aplikace. 10. EXTEND UC101: Log in IF návštěvník se chce přihlásit do systému. Alternative flows: 5a. Návštěvník zadal ve formuláři nevalidní data. 1. Systém upozorní návštěvníka na nevalidní data, která zadal. 2. Návštěvník pokračuje krokem 4 z hlavního scénáře. Frequency of Occurrence: Málo – frekvence závisí na počtu návštěvníků webové prezentace.
3.2.4
UC3: Front office
Tato část obsahuje popis případů užití, které vykonávají pracovníci CRM systému (manažeři a administrátoři). Skupina případů užití pokrývá operace z 54
3.2. Model případů užití části Front office – správu klientů, vystavování a správu fakturu apod. Je zobrazena na diagramu případů užití 3.5.
Obrázek 3.5: UC model - UC3: Front office
Případ užití - UC301: Manage manager Context of Use: Administrátor CRM systému chce spravovat účty manažerů. Scope: Front office Level: Cíl uživatele Primary actor: Administrátor Stakeholders and Interests: – Administrátor: Chce spravovat účty manažerů – zobrazit seznam účtů, přidat nový, upravit stávající, deaktivovat účet. Preconditions: Uživatel je autentizován a přihlášen. Success End: Administrátor upravil účet manažera. Main success scenario: 1. Administrátor chce upravit účet manažera. 2. Administrátor spustí akci pro zobrazení seznamu manažerů. 3. Systém zobrazí seznam manažerů CRM systému, možnost pro řazení a filtrování tohoto seznamu (podle jména), možnost pro přechod na detail manažera a možnost pro přidání nového manažera. 4. Administrátor zvolí akci pro přechod na detail vybraného manažera. 5. Systém zobrazí detailní informace o zvoleném manažerovi – jméno, příjmení, přihlašovací jméno, email, stav jeho účtu, seznam jeho klientů. Administrátor může editovat pouze email nebo stav jeho účtu (povolen, blokován). 6. Administrátor upraví nějaký záznam (email, stav účtu). 7. Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Administrátor opakuje krok 6 do té doby, než provede všechny požadované změny. 8. Administrátor zvolí akci pro uložení změn. 9. Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení.
55
3. Analýza
Alternative flows: *a. Kdykoli se může uživatel odhlásit ze systému: 1. Uživatel zvolí odhlášení ze systému. 2. IF odhlášení po kroku 6 z hlavního scénáře THEN systém pokračuje krokem *b. 3. Systém odhlásí uživatele INCLUDE: UC102: Log out. *b. Uživatel chce opustit obrazovku. 1. IF uživatel se snaží opustit obrazovku po kroku 6 z hlavního scénáře THEN systém upozorní uživatele, že se pokouší opustit obrazovku a neuložil provedené změny. 2. Uživatel pokračuje krokem 8 hlavního scénáře. 2a. Uživatel nechce změny uložit, ignoruje upozornění. 3. Systém přejde na jinou obrazovku. 4a. Uživatel chce seřadit data v seznamu manažerů. 1. Uživatel zvolí akci pro seřazení seznamu podle vybraného sloupce (jméno, příjmení). 2. Systém seřadí seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4b. Uživatel chce filtrovat data v seznamu manažerů. 1. Uživatel zvolí akci pro filtrování seznamu podle vybraného sloupce (jméno, příjmení). 2. Systém aplikuje filtr na seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4c. Uživatel chce přidat nového manažera. 1. Uživatel zvolí akci pro přidání nového manažera. 2. Systém zobrazí formulář pro přidání nového manažera, ve kterém může uživatel vyplnit jméno, příjmení, email, přihlašovací jméno a jazyk. 3. Uživatel vyplní formulář a potvrdí přidání nového manažera. 3a. Uživatel chce zrušit přidání nového manažera. 1. Uživatel zvolí akci pro zrušení přidání nového manažera. 2. Systém pokračuje krokem 3 z hlavního scénáře. 4. Systém zkontroluje validitu záznamů, vytvoří nového manažera podle zadaných dat z formuláře, povolí jeho účet, vygeneruje přihlašovací heslo, uloží ho a informuje uživatele o úspěšném uložení záznamů. 4a. Uživatel zadal nevalidní data nebo nezadal všechna povinná data. 1. Systém upozorní uživatele na povinná nebo nevalidní data, která zadal. 2. Systém pokračuje krokem 4c.2 z alternativního scénáře. 5. Systém odešle na zadaný email manažera pozvánku do aplikace s přihlašovacími údaji. 6. Systém pokračuje krokem 3 hlavního scénáře. 8a. Uživatel chce zrušit úpravu záznamů manažera. 1. Uživatel zvolí akci pro zrušení úpravy záznamů manažera. 2. Systém pokračuje krokem 3 hlavního scénáře. 9a. Uživatel zadal nevalidní data. 1. Systém upozorní uživatele na nevalidní data, která zadal. 2. Uživatel pokračuje krokem 6 hlavního scénáře. Frequency of Occurrence: Málo – administrátor nespravuje účty manažerů často.
Případ užití - UC303: Manage CRM service price Context of Use: Administrátor CRM systému chce změnit cenu za měsíční použití CRM služeb jedním uživatelem. Scope: Front office Level: Cíl uživatele Primary actor: Administrátor Stakeholders and Interests: – Uživatel: Chce znát aktuální cenu za použití CRM služeb. – Administrátor: Chce změnit cenu za použití CRM služeb.
56
3.2. Model případů užití – Poskytovatel CRM systému: Chce změnit cenu za použití CRM služeb. Preconditions: Uživatel je autentizován a přihlášen. Success End: Administrátor změnil cenu za měsíční používání CRM služeb. Main success scenario: 1. Administrátor chce změnit měsíční cenu za použití CRM služeb. 2. Administrátor spustí akci pro správu ceny za CRM služby. 3. Systém zobrazí měsíční cenu za použití CRM služeb a měnu ceny. Administrátor může oba záznamy editovat. 4. Administrátor upraví nějaký záznam (cenu, měnu). 5. Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Administrátor opakuje krok 4 do té doby, než provede všechny požadované změny. 6. Administrátor zvolí akci pro uložení změn. 7. Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení. Alternative flows: *a. Kdykoli se může uživatel odhlásit ze systému: 1. Uživatel zvolí odhlášení ze systému. 2. IF odhlášení po kroku 4 z hlavního scénáře THEN systém pokračuje krokem *b. 3. Systém odhlásí uživatele INCLUDE: UC102: Log out. *b. Uživatel chce opustit obrazovku. 1. IF uživatel se snaží opustit obrazovku po kroku 4 z hlavního scénáře THEN systém upozorní uživatele, že se pokouší opustit obrazovku a neuložil provedené změny. 2. Uživatel pokračuje krokem 6 hlavního scénáře. 2a. Uživatel nechce změny uložit, ignoruje upozornění. 3. Systém přejde na jinou obrazovku. 7a. Uživatel zadal nevalidní data. 1. Systém upozorní uživatele na nevalidní data, která zadal. 2. Uživatel pokračuje krokem 4 hlavního scénáře. Frequency of Occurrence: Málo – cena služeb se bude měnit méně než jedenkrát ročně.
Případ užití - UC311: Manage client Context of Use: Manažer CRM systému spravuje účty klientů. Scope: Front office Level: Cíl uživatele Primary actor: Manažer Stakeholders and Interests: – Manažer: Chce spravovat účty klientů – zobrazit seznam klientů, přidat nového, upravit stávající, deaktivovat klienta. – Klient: Chce aby mu byl vytvořen nebo upraven účet. – Poskytovatel CRM systému: Chce získat nového klienta a mít aktuální data o klientech. Preconditions: Uživatel je autentizován a přihlášen. Success End: Manažer upravil účet klienta. Main success scenario: 1. Manažer chce upravit účet klienta. 2. Manažer spustí akci pro zobrazení seznamu klientů. 3. Systém zobrazí seznam klientů, možnost pro řazení a filtrování tohoto seznamu (podle názvu, adresy, zodpovědné osoby a počtu uživatelů), možnost pro přechod na detail klienta a možnost pro přidání nového klienta. 4. Manažer zvolí akci pro přechod na detail vybraného klienta.
57
3. Analýza 5. Systém zobrazí detailní informace o zvoleném klientovi – název, identifikační číslo, typ účtu, email, max. a skutečný počet uživatelů, telefonní kontakt, adresu, zodpovědnou osobu, seznam jeho uživatelů apod. Manažer může editovat všechny tyto záznamy. 6. Manažer upraví nějaký záznam. 7. Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Manažer opakuje krok 6 do té doby, než provede všechny požadované změny. 8. Manažer zvolí akci pro uložení změn. 9. Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení. Alternative flows: *a. Kdykoli se může uživatel odhlásit ze systému: 1. Uživatel zvolí odhlášení ze systému. 2. IF odhlášení po kroku 6 z hlavního scénáře THEN systém pokračuje krokem *b. 3. Systém odhlásí uživatele INCLUDE: UC102: Log out. *b. Uživatel chce opustit obrazovku. 1. IF uživatel se snaží opustit obrazovku po kroku 6 z hlavního scénáře THEN systém upozorní uživatele, že se pokouší opustit obrazovku a neuložil provedené změny. 2. Uživatel pokračuje krokem 8 hlavního scénáře. 2a. Uživatel nechce změny uložit, ignoruje upozornění. 3. Systém přejde na jinou obrazovku. 4a. Uživatel chce seřadit data v seznamu klientů. 1. Uživatel zvolí akci pro seřazení seznamu podle vybraného sloupce (název, adresa). 2. Systém seřadí seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4b. Uživatel chce filtrovat data v seznamu klientů. 1. Uživatel zvolí akci pro filtrování seznamu podle vybraného sloupce (název, adresa). 2. Systém aplikuje filtr na seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4c. Uživatel chce přidat nového klienta. 1. Uživatel zvolí akci pro přidání nového klienta. 2. Systém zobrazí formulář pro přidání nového klienta a jeho zodpovědné osoby, ve kterém může uživatel vyplnit název, adresu, kontaktní informace, max. počet uživatelů, typ účtu klienta a jméno, příjmení, email, uživatelské jméno zodpovědné osoby. 3. Uživatel vyplní formulář a potvrdí přidání nového klienta a zodpovědné osoby. 3a. Uživatel chce zrušit přidání nového klienta. 1. Uživatel zvolí akci pro zrušení přidání nového klienta. 2. Systém pokračuje krokem 3 z hlavního scénáře. 4. Systém zkontroluje validitu záznamů, vytvoří nového klienta a zodpovědnou osobu podle zadaných dat z formuláře, vygeneruje přihlašovací heslo pro účet zodpovědné osoby, uloží ho. 4a. Uživatel zadal nevalidní data nebo nezadal všechna povinná data. 1. Systém upozorní uživatele na povinná nebo nevalidní data, která zadal. 2. Systém pokračuje krokem 4c.2 z alternativního scénáře. 5. Systém odešle na email zodpovědné osoby pozvánku do aplikace s přihlašovacími údaji. 6. Systém informuje uživatele o úspěšném uložení záznamů. 7. Systém pokračuje krokem 3 hlavního scénáře. 8a. Uživatel chce zrušit úpravu záznamů klienta. 1. Uživatel zvolí akci pro zrušení úpravy záznamů klienta. 2. Systém pokračuje krokem 3 hlavního scénáře. 9a. Uživatel zadal nevalidní data. 1. Systém upozorní uživatele na nevalidní data, která zadal. 2. Uživatel pokračuje krokem 6 hlavního scénáře. Frequency of Occurrence: Často – správa klientů je hlavní aktivitou manažerů.
58
3.2. Model případů užití Případ užití - UC313: Send invoices Context of Use: Systém vygeneruje pro každého klienta fakturu za používání CRM služeb a odešle ji klientům na email. Scope: Front office Level: Funkce Primary actor: Systém Stakeholders and Interests: – Klient: Chce obdržet měsíční vyúčtování a fakturu za konzumované služby CRM systému. – Poskytovatel CRM systému: Chce pro každého klienta vystavit měsíční fakturu za poskytované CRM služby. – Systém: Chce zkompletovat a odeslat faktury pro všechny klienty. Preconditions: – Success End: Systém zkompletoval a odeslal faktury za používání CRM služeb všem klientům CRM systému. Trigger: Systém spouští scénář jedenkrát za měsíc, vždy pátý den v měsíci v 5:00. Main success scenario: 1. Systém chce zkompletovat a odeslat faktury klientům. 2. Systém vypočte částku za měsíční používání CRM služeb pro klienta INCLUDE UC314: Calculate month price for services. 3. Systém sestaví měsíční fakturu pro klienta, která obsahuje číslo faktury, datum splatnosti a vystavení, částku za služby, fakturované položky a údaje o poskytovateli CRM služeb a klientovi (fakturační adresa apod.). 4. Systém odešle fakturu na email klienta a jeho zodpovědné osoby. Systém opakuje kroky 2 až 4 pro všechny klienty CRM systému. Alternative flows: – Frequency of Occurrence: Málo – jedenkrát měsíčně.
Případ užití - UC314: Calculate month price for services Context of Use: Systém vypočítá částku za měsíční používání CRM služeb pro zvoleného klienta. Scope: Front office Level: Funkce Primary actor: Systém Stakeholders and Interests: – Klient: Chce na faktuře obdržet správnou částku za používání CRM služeb. – Poskytovatel CRM systému: Chce, aby byly uvedeny správné částky na fakturách vystavených klientům. – Systém: Chce správně spočítat částku za měsíční používání CRM služeb klientem. Preconditions: – Success End: Systém spočítal částku za měsíční používání CRM služeb klientem. Main success scenario: 1. Systém chce spočítat částku za měsíční používání CRM služeb pro zvoleného klienta. 2. Systém vynásobí aktuální počet uživatelů klienta měsíční cenou za použití CRM služeb. 3. Systém vrátí výsledek výpočtu. Alternative flows: – Frequency of Occurrence: Málo – při odesílání faktur klientům a při správě faktur klientů.
59
3. Analýza
3.2.5
UC4: CRM Business Operations
Tato část obsahuje popis případů užití, které vykonávají pracovníci klienta CRM systému (uživatelé a zodpovědné osoby). Skupina případů užití pokrývá stěžejní operace CRM aplikace – správu obchodních entit (účtů, kontaktů, produktů, obchodních případů, aktivit, ceníků), zobrazení reportů apod. Je zobrazena na diagramu případů užití 3.6.
Obrázek 3.6: UC model - UC4: CRM Business Operations Abstraktní případ užití - UC450: Manage business entity Context of Use: Uživatel spravuje obchodní entitu (účet, kontakt, produkt, obchodní případ, aktivitu nebo ceník), může zobrazit seznam všech entit daného typu, entity upravovat, přidávat, komentovat apod. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce spravovat obchodní entity (účty, kontakty, produkty, obchodní případy, aktivity nebo ceníky), zobrazovat jejich seznamy, upravovat je a přidávat nové. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel upravil obchodní entitu. Main success scenario: 1. Uživatel chce upravit obchodní entitu. 2. Uživatel spustí akci pro zobrazení seznamu obchodních entit.
60
3.2. Model případů užití 3. Systém zobrazí seznam obchodních entit, možnost pro řazení a filtrování tohoto seznamu, možnost pro přechod na detail entity a možnost pro přidání nové entity. 4. Uživatel zvolí akci pro přechod na detail zvolené entity. 5. Systém zobrazí detailní informace o zvolené entitě, komentáře a vazby na další entity. Uživatel může editovat záznamy, komentovat entitu a zobrazit vazby na další entity. 6. Uživatel upraví nějaký záznam. 7. Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Uživatel opakuje krok 6 do té doby, než provede všechny požadované změny. 8. Uživatel zvolí akci pro uložení změn. 9. Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení. Alternative flows: *a. Kdykoli se může uživatel odhlásit ze systému: 1. Uživatel zvolí odhlášení ze systému. 2. IF odhlášení po kroku 6 z hlavního scénáře THEN systém pokračuje krokem *b. 3. Systém odhlásí uživatele INCLUDE: UC102: Log out. *b. Uživatel chce opustit obrazovku. 1. IF uživatel se snaží opustit obrazovku po kroku 6 z hlavního scénáře THEN systém upozorní uživatele, že se pokouší opustit obrazovku a neuložil provedené změny. 2. Uživatel pokračuje krokem 8 hlavního scénáře. 2a. Uživatel nechce změny uložit, ignoruje upozornění. 3. Systém přejde na jinou obrazovku. 4a. Uživatel chce seřadit data v seznamu entit. 1. Uživatel zvolí akci pro seřazení seznamu podle vybraného sloupce. 2. Systém seřadí seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4b. Uživatel chce filtrovat data v seznamu entit. 1. Uživatel zvolí akci pro filtrování seznamu podle vybraného sloupce. 2. Systém aplikuje filtr na seznam. 3. Systém pokračuje krokem 3 hlavního scénáře. 4c. Uživatel chce přidat novou entitu. 1. Uživatel zvolí akci pro přidání nové entity. 2. Systém zobrazí formulář pro přidání nové entity. 3. Uživatel vyplní formulář a potvrdí přidání nové entity. 3a. Uživatel chce zrušit přidání nové entity. 1. Uživatel zvolí akci pro zrušení přidání nové entity. 2. Systém pokračuje krokem 3 z hlavního scénáře. 4. Systém zkontroluje validitu záznamů, vytvoří novou entitu. 4a. Uživatel zadal nevalidní data nebo nezadal všechna povinná data. 1. Systém upozorní uživatele na povinná nebo nevalidní data, která zadal. 2. Systém pokračuje krokem 4c.2 z alternativního scénáře. 5. Systém informuje uživatele o úspěšném uložení záznamů. 6. Systém pokračuje krokem 3 hlavního scénáře. 6a. Uživatel chce přidat komentář INCLUDE UC451: Comment business entity. 6b. Uživatel chce zobrazit vazby na další entity INCLUDE UC453: Show connections. 6c. Uživatel chce zobrazit nápovědu k entitě INCLUDE UC452: Show business entity help. 8a. Uživatel chce zrušit úpravu záznamů entity. 1. Uživatel zvolí akci pro zrušení úpravy záznamů entity. 2. Systém pokračuje krokem 3 hlavního scénáře. 9a. Uživatel zadal nevalidní data. 1. Systém upozorní uživatele na nevalidní data, která zadal. 2. Uživatel pokračuje krokem 6 hlavního scénáře.
61
3. Analýza Frequency of Occurrence: Velmi často – tento případ užití se vyskytuje nejčastěji, několikrát denně ho spouští většina uživatelů CRM aplikace.
Případ užití - UC401: Manage account Parent: UC450: Manage business entity Context of Use: Uživatel spravuje účet (společnost, firmu), může zobrazit seznam všech účtů, účty upravovat, přidávat, komentovat apod. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce spravovat účty, zobrazovat seznam účtů, upravovat účty a přidávat nové. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel upravil účet. Main success scenario: 1. (o1.) Uživatel chce upravit účet. 2. (o2.) Uživatel spustí akci pro zobrazení seznamu účtů. 3. (o3.) Systém zobrazí seznam účtů, možnost pro řazení a filtrování tohoto seznamu (podle názvu, vlastníka, stavu, typu, adresy atd.), možnost pro přechod na detail účtu a možnost pro přidání nového účtu. 4. (o4.) Uživatel zvolí akci pro přechod na detail zvoleného účtu. 5. (o5.) Systém zobrazí detailní informace o zvoleném účtu (název, kontaktní informace, stav, typ, zaměření, vlastníka), seznam zaměstnanců, komentáře a vazby na další entity (obchodní případy, kontakty, aktivity). Uživatel může editovat záznamy, spravovat zaměstnance, přidat komentář k účtu a zobrazit vazby na další entity. 6. (6.) Uživatel upraví nějaký záznam. 7. (7.) Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Uživatel opakuje krok 6 do té doby, než provede všechny požadované změny. 8. (8.) Uživatel zvolí akci pro uložení změn. 9. (9.) Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení. Alternative flows: *a. (*a.) Kdykoli se může uživatel odhlásit ze systému. *b. (*b.) Uživatel chce opustit obrazovku. 4a. (o4a.) Uživatel chce seřadit data v seznamu účtů. 4b. (o4b.) Uživatel chce filtrovat data v seznamu účtů. 4c. (o4c.) Uživatel chce přidat nový účet (ve formuláři v podkroku 2 může vyplnit název účtu, typ, stav, zaměření, kontaktní údaje atd.). 6a. (6a.) Uživatel chce přidat komentář INCLUDE UC451: Comment business entity. 6b. (6b.) Už. chce zobrazit vazby na další entity INCLUDE UC453: Show connections. 6c. (6c.) Už. chce zobrazit nápovědu k entitě INCLUDE UC452: Show business entity help. 6d. Uživatel chce spravovat zaměstnance (kontakty) přiřazené k účtu. 1. Uživatel zvolí přidání zaměstnance (kontaktu). 1a. Uživatel chce odebrat zaměstnance. 1. Uživatel zvolí odebraní zaměstnance. 2. Systém zruší zaměstnanecký vztah a informuje o tom uživatele. 3. Systém pokračuje krokem 5 hlavního scénáře. 2. Systém zobrazí seznam kontaktů (osob). 3. Uživatel vybere kontakt a nastaví její zaměstnanecký vztah k účtu (společnosti). 4. Systém uloží zaměstnanecký vztah a informuje o tom uživatele. 5. Systém pokračuje krokem 5 hlavního scénáře. 8a. (o8a.) Uživatel chce zrušit úpravu záznamů účtu.
62
3.2. Model případů užití 9a. (9a.) Uživatel zadal nevalidní data. Frequency of Occurrence: Velmi často – tento případ užití spouští několikrát denně většina uživatelů CRM aplikace.
Případ užití - UC404: Manage business case Parent: UC450: Manage business entity Context of Use: Uživatel spravuje obchodní případ, může zobrazit seznam všech o. p., upravit nějaký, přidat nový, okomentovat apod. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce spravovat o. p., zobrazovat jejich seznam, upravovat a přidávat nové. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel upravil obchodní případ. Main success scenario: 1. (o1.) Uživatel chce upravit obchodní případ. 2. (o2.) Uživatel spustí akci pro zobrazení seznamu obchodních případů. 3. (o3.) Systém zobrazí seznam obchodních případů, možnost pro řazení a filtrování tohoto seznamu (podle názvu, předmětu prodeje, účtu, vlastníka, stavu, ceny atd.), možnost pro přechod na detail o. p. a možnost pro přidání nového o. p. 4. (o4.) Uživatel zvolí akci pro přechod na detail zvoleného obchodního případu. 5. (o5.) Systém zobrazí detailní informace o zvoleném obchodním případu (předmět prodeje, vlastníka, stav, pravděpodobnost, cenu, náklady), navázaný účet a kontaktní osobu, seznam produktů, komentáře a vazby na další entity (aktivity). Uživatel může editovat záznamy, spravovat navázaný kontakt, spravovat seznam produktů, přidat komentář k účtu a zobrazit vazby na další entity. 6. (6.) Uživatel upraví nějaký záznam. 7. (7.) Systém upozorní uživatele, že upravil záznamy a měl by uložit provedené změny. Uživatel opakuje krok 6 do té doby, než provede všechny požadované změny. 8. (8.) Uživatel zvolí akci pro uložení změn. 9. (9.) Systém zkontroluje validitu záznamů, uloží změny a informuje o úspěšném uložení. Alternative flows: *a. (*a.) Kdykoli se může uživatel odhlásit ze systému. *b. (*b.) Uživatel chce opustit obrazovku. 4a. (o4a.) Uživatel chce seřadit data v seznamu obchodních případů. 4b. (o4b.) Uživatel chce filtrovat data v seznamu obchodních případů. 4c. (o4c.) Uživatel chce přidat nový obchodní případ (ve formuláři v podkroku 2 může vyplnit předmět prodeje, pravděpodobnost, cenu, navázat účet atd.). 6a. (6a.) Uživatel chce přidat komentář INCLUDE UC451: Comment business entity. 6b. (6b.) Už. chce zobrazit vazby na další entity INCLUDE UC453: Show connections. 6c. (6c.) Už. chce zobrazit nápovědu k entitě INCLUDE UC452: Show business entity help. 6d. Uživatel chce spravovat navázanou kontaktní osobu. 1. Uživatel zvolí přidání kontaktní osoby. 1a. Uživatel chce odebrat kontaktní osobu. 1. Uživatel zvolí odebraní kontaktní osoby. 2. Systém odebere vazbu a informuje o tom uživatele. 3. Systém pokračuje krokem 5 hlavního scénáře. 2. Systém zobrazí seznam zaměstnanců navázaného účtu. 3. Uživatel vybere kontaktní osobu se seznamu zaměstnanců.
63
3. Analýza 4. Systém naváže kontaktní osobu na obchodní případ a informuje o tom uživatele. 5. Systém pokračuje krokem 5 hlavního scénáře. 6e. Uživatel chce spravovat seznam produktů obchodního případu. 1. Uživatel zvolí přidání produktu. 1a. Uživatel chce odebrat produkt. 1. Uživatel zvolí odebraní produktu. 2. Systém odebere produkt a informuje o tom uživatele. 3. Systém pokračuje krokem 5 hlavního scénáře. 1b. Uživatel chce upravit položku v seznamu produktů. 1. Uživatel upraví doplňující informace položky (název, cenu, slevu, množství). 2. Systém pokračuje krokem 7 hlavního scénáře. 2. Systém zobrazí seznam dostupných produktů. 3. Uživatel vybere produkt. 4. Systém přidá produkt do seznamu produktů obchodního případu. 5. Systém pokračuje krokem 5 hlavního scénáře. 8a. (o8a.) Uživatel chce zrušit úpravu záznamů obchodního případu. 9a. (9a.) Uživatel zadal nevalidní data. Frequency of Occurrence: Velmi často – tento případ užití spouští několikrát denně většina uživatelů CRM aplikace.
Případ užití - UC451: Comment business entity Context of Use: Uživatel komentuje obchodní entitu (účet, kontakt, produkt, ceník, aktivitu, obchodní případ) nebo odpovídá na jiný komentář. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce komentovat obchodní entity a odpovídat na komentáře kolegů. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel okomentoval obchodní entitu. Main success scenario: 1. Uživatel chce komentovat obchodní entitu. 2. Uživatel okomentuje obchodní entitu a potvrdí vložení komentáře. 3. Systém vloží komentář k entitě a informuje o tom uživatele. Alternative flows: 2a. Uživatel chce vložit odpověď na komentář. 1. Uživatel napíše odpověď a potvrdí její odeslání. 2. Systém vloží odpověď ke komentáři a informuje o tom uživatele. 3. Systém upozorní na odpověď uživatele, který vložil původní komentář a i všechny uživatele, kteří na něj odpovídali INCLUDE UC601: Remind user. Frequency of Occurrence: Často – komunikace ohledně každé obchodní entity.
Případ užití - UC409: Show reports Context of Use: Uživatel nastaví parametry pro zobrazení reportu a report zobrazí. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests:
64
3.2. Model případů užití – Uživatel: Chce zobrazit vývoj prodeje na základě různých parametrů. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel zobrazil parametrizovaný report vývoje prodeje. Main success scenario: 1. Uživatel chce zobrazit report, podle parametrů, které zadá. 2. Uživatel zadá parametry reportu (časové období, prodejce, produkt). 3. Systém graf vývoje prodeje na základě stanovených parametrů. Alternative flows: 3a. Nelze sestavit graf na základě stanovených parametrů. 1. Systém informuje uživatele, že graf vývoj prodeje nelze sestavit. Frequency of Occurrence: Málo – vývoj prodeje je sledován cca jedenkrát týdně.
3.2.6
UC6: CRM Reminder
Tato část obsahuje popis případů užití, které se týkají připomínek – upozornění na připomínku, zobrazení připomínky uživatelem. Skupina případů užití je zobrazena na diagramu případů užití 3.7.
Obrázek 3.7: UC model - UC6: CRM Reminder Případ užití - UC601: Remind user Context of Use: Systém upozorní uživatele na připomínku (komunikaci, varování, alarm). Scope: CRM aplikace Level: Funkce Primary actor: Systém Stakeholders and Interests: – Uživatel: Chce být upozorněn, když někdo odpoví na jeho komentář, změní vlastnictví jeho entity nebo na nadcházející aktivitu, kterou má vykonat. Preconditions: –
65
3. Analýza Success End: Systém upozornil uživatele na připomínku. Trigger: Někdo odpověděl na komentář uživatele nebo je čas na připomenutí aktivity uživateli nebo někdo změnil vlastníka obchodní entity, kterou vlastnil uživatel. Main success scenario: 1. Systém upozorní uživatele na připomínku, která spustila případ užití. Frequency of Occurrence: Velmi často – viz trigger.
Abstratní případ užití - UC602: Show reminder Context of Use: Uživatel zobrazí připomínku, na kterou ho upozornil systém(komunikaci, varování, alarm). Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce zobrazit detail připomínky, na kterou ho upozornil systém. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel zobrazil připomínku. Main success scenario: 1. Uživatel chce zobrazit připomínky. 2. Uživatel zvolí akci pro zobrazení seznamu připomínek. 3. Systém zobrazí seznam připomínek. 4. Systém deaktivuje upozornění na zobrazené připomínky. Frequency of Occurrence: Velmi často – vždy, když je uživatel na něco upozorněn.
Případ užití - UC604: Show communication Context of Use: Uživatel zobrazí připomínku na komunikaci. Scope: CRM aplikace Level: Cíl uživatele Primary actor: Uživatel Stakeholders and Interests: – Uživatel: Chce zobrazit detail připomínky na komunikaci, na kterou ho upozornil systém. Preconditions: Uživatel je autentizován a přihlášen. Success End: Uživatel zobrazil připomínku na komunikaci. Main success scenario: 1. (o1.) Uživatel chce zobrazit připomínky na komunikaci. 2. (o2.) Uživatel zvolí akci pro zobrazení seznamu připomínek na komunikaci. 3. (o3.) Systém zobrazí seznam připomínek na komunikaci. U každé připomínky je zobrazeno jméno uživatele, který odpověď vložil, text odpovědi a obchodní entita, na kterou se komentář váže. Uživatel může odpovědět na komentář nebo zobrazit obchodní entitu. 4. (4.) Systém deaktivuje upozornění na zobrazené připomínky. 5. EXTEND UC451: Comment business entity IF uživatel chce odpovědět na komentář. Alternative flows: 4a. Uživatel chce zobrazit detail obchodní entity, na kterou se váže připomínka INCLUDE UC450: Manage business entity. Frequency of Occurrence: Velmi často – vždy, někdo odpoví na komentář uživatele.
66
Kapitola
Návrh V této kapitole je popsán návrh uživatelského rozhraní, výběr prostředí implementace a zvoleného vývojového prostředí, popsána logická a fyzická architektura systému a fyzický datový model.
4.1
Návrh uživatelského rozhraní
Jak bylo zmíněno v úvodní studii, existuje riziko, že koncový uživatel nebude schopen ovládat aplikaci, kvůli špatně navrženému uživatelskému rozhraní, což povede k tomu, že se systém nebude používat. Aby bylo toto riziko eliminováno je důležité věnovat pozornost návrhu uživatelského rozhraní a jeho testování. Existuje několik způsobů a metodik pro návrh uživatelského rozhraní. Jelikož je systém CRM webovou aplikací, rozhodl jsem se pro návrh navigace mezi stránkami a kompozice stránek využít webovou metodiku. Rozhodoval jsem se mezi dvěma metodikami – WebML a UWE. Ačkoli mám zkušenosti s metodikou WebML, zvolil jsem metodiku UWE. Důvodem volby byla její jednoduchost, založení na standardu UML, podpora v CASE nástrojích a podobnost navigačního modelu UWE s „task modelem“, který je poslední fází metody tvorby návrhu uživatelského rozhraní, která je založena na popisu a vizualizaci „tasků“ (úloh). V metodice WebML se navíc znázorňuje model navigace i kompozice do jednoho diagramu (hypertextového modelu), který je poté velmi rozsáhlý a obtížně prezentovatelný. Dalším krokem návrhu UI je vytvoření „mockup“ prototypu systému, čili vytvoření ilustrací několika obrazovek systému, které slouží jako podklady k testování návrhu UI. V závěru kapitoly je provedeno vyhodnocení tohoto testování.
4.1.1
Návrh navigace a kompozice
Jak již bylo uvedeno, pro návrh navigace a kompozice byla použita metodika UWE (více viz kapitola 1.5), konkrétně navigační a prezentační model. V me67
4
4. Návrh todice UWE se používají dva modely jako podklad pro tvorbu navigačního modelu - model požadavků a obsahu. Ty jsou zde vynechány a zastoupeny již hotovými modely systému z kapitoly analýza (model případů užití 3.2 a konceptuální datový model 3.1). Na navigačním modelu systému jsou zobrazeny navigační a procesní uzly a odkazy (viz obrázek 4.1). Na diagramu není zobrazeno rozhraní „Front office“, jen část webové prezentace a CRM aplikace. Do aplikace CRM lze přistoupit z webové prezentace po přihlášení viz byznys proces „Login“. Webová prezentace dále nabízí možnost vyzkoušení demo verze aplikace (TryDemo), zaregistrování (Register) nebo objednání (OrderCrm). Po vstupu do CRM aplikace je uživatel přesměrován na domovskou stránku této části označenou stereotypem „isHome“ – nástěnku (Dashboard). Poté může uživatel pokračovat na jakýkoli uzel diagramu, který je označen stereotypem „isLandmark“, který značí, že je uzel dostupný ze kteréhokoli uzlu navigačního grafu. Nejdůležitějšími uzly grafu jsou seznamy účtů (AccountsList) a kontaktů (ContactsList), které dědí společné vlastnosti z obecného seznamu obchodních entit (BusinessEntitiesList) – tj. řazení a filtrování prvků seznamu (FilterList, OrderList), mazání entit seznamu (RemoveEntity). Ze seznamů lze přejít na konkrétní uzel obsahující detailní informace o obchodní entitě (Account resp. Contact) nebo spustit proces vytvoření nové entity (CreateAccount resp. CreateContact). Detaily obchodních entit opět dědí vlastnosti od obecného uzlu (BusinessEntity) – tj. uložení změn editování (UpdateEntity), smazání entity, zobrazení navázaných entit (RelatedEntityList), navázání existující entity (CreateRelatedBusinessEntity), zobrazení komunikace. Model prezentace viz obrázek 4.2 zobrazuje abstraktní kompozici UI pomocí prezentačních elementů, kterých existuje hned několik (viz tabulka stereotypů UWE profilu v příloze B.2). Na diagramu je zobrazena pouze malá část celého prezentačního modelu – domovská stránka aplikace CRM a prezentační skupiny týkající se účtů. Hlavním elementem je prezentační stránka reprezentující domovskou stránku aplikace CRM (CrmHome). Ta obsahuje obrázek loga (CrmLogo), horní menu (TopBarMenu), hlavní menu (MainMenu) a panel s alternativami obsahu (ContentPanelAlternatives), ve kterém může být viditelná jedna z uvedených prezentačních skupin. Výchozí prezentační skupinou je nástěnka (Dashboard). Jednou z dalších alternativ jsou například účty (Accounts). Tato prezentační skupina obsahuje kontejner pro zobrazení seznamu účtů (AccountList). Každá položka seznamu je tvořena odkazem na detail účtu (navázán na název (Name)), typem účtu (Type), vlastníkem (Owner) a odkazem na skrytý formulář smazání účtu (DeleteAccount), který se vyvolá po přechodu na něj. Účty dále obsahují vstupní pole a selekce pro filtrování seznamu (NameFilter atd.) a tlačítko s odkazem na formulář vytvoření nového účtu. Dalším zajímavým prvkem je detail účtu (Account), který obsahuje panel záložek (ActualTabPanelAlternatives) se třemi alternativami. Výchozí záložka, která je zobrazena, obsahuje detailní informace účtu (AccountDetailTab). 68
4.1. Návrh uživatelského rozhraní
Obrázek 4.1: Návrh navigace v UWE
Obrázek 4.2: Návrh prezentace v UWE
69
4. Návrh
4.1.2
Mockup prototyp
Termínem mockup rozumíme low-fidelity50 prototyp aplikace (např. papírové ilustrace, snímky obrazovek nebo jednoduché obrazovky s limitovanou možností interakce). Prototypování je důležitou částí návrhu UI, ve které jsou vytvořeny, vyhodnoceny a propracovány návrhy až dosáhnou požadovaného stupně použitelnosti. Prototypů je celá řada od jednoduchých náčrtků (lowfidelity prototypy) až po funkční prototypy celých systémů, které obsahují většinu funkcionality koncového systému (high-fidelity). V rámci mockup prototypu byla vytvořena sada návrhů obrazovek CRM aplikace (např. obrázek 4.3). Další náčrtky obrazovek, které reprezentují vzorový průchod aplikací, jsou součástí přílohy (viz obrázky B.3, B.4, B.5, B.6, B.7 a B.8). Mockup prototyp vychází z předešlého návrhu navigace a kompozice, který v mnohých ohledech rozšiřuje. Zakládá rovněž na doporučení pro návrh webových aplikací viz Krug [25] a účelné použití komponent viz Tidwell [46].
Obrázek 4.3: Mockup prototyp - Úprava účtu
4.1.3
Testování návrhu UI
Návrh uživatelského rozhraní byl testován jednou z metod testování bez uživatelů – provedením heuristické analýzy na mockup prototypu. Po realizaci 50
Low-fidelity prototyp je neúplný, zběžný náčrtek, který má určité charakteristiky cílového produktu, ale je velmi jednoduchý. Vytváří se za účelem rychlé produkce prototypu pro testování všeobecných konceptů.
70
4.1. Návrh uživatelského rozhraní systému bylo provedeno testování uživatelského rozhraní s uživateli – testování použitelnosti (viz kapitola 6.3). Cílem heuristické analýzy je nalezení možných problémů s použitelností systému viz Nielsen [32]. Provádí ji několik (ideálně pět) expertů nezávisle na sobě, kteří proházejí rozhraní, definují při tom svůj názor na něj a kontrolují, zda splňuje určitou sadu principů neboli heuristik. Původní Nielsenova heuristika [32] obsahovala deset pravidel. Ty se postupem času díky novým zařízením a přístupům k návrhu vyvinuly v tyto: 1. Viditelnost stavu systému: Uživatelům je poskytnuta informace (zpětná vazba) o tom co systém provádí. 2. Shoda systému s realitou: Použití termínů a konceptů, které cílová skupina dobře zná. Informace by měly odpovídat tomu, co uživatelé očekávají a na co jsou zvyklí z reálného světa. 3. Minimální zodpovědnost a stres: Uživatelé by měli mít pocit, že mají interakci se systémem pod kontrolou. 4. Zachování konzistence a standardů: Ovládání, ikony, terminologie, podoba chybových hlášek by měla být konzistentní napříč rozhraním. Měly by být dodrženy standardy pro danou platformu. 5. Prevence chyb: Rozhraní obsahuje prvky, které slouží k tomu, aby interakce uživatele se systémem nevedla k chybovému stavu. 6. Rozpoznání místo rozvzpomínání: Snížení zátěže na „pamatování si“ uživatele uvedením známých ikon a akcí kdekoli je to účelné. 7. Flexibilita a efektivita použití: Systém by měl být snadno použitelný pro začátečníky a pokročilým uživatelům by měl nabídnout urychlující řešení apod. 8. Estetický a minimalistický design: Vyvarování se zobrazení nadbytečného množství informací a designových prvků na úkor důležitých informací. 9. Smysluplné chybové hlášky: Poskytnutí chybových hlášek, které instruují k tomu, co a jak opravit. 10. Nápověda a dokumentace: Měla by být přístupná nápověda, dokumentace a případně uživatelská podpora.
Heuristická analýza Heuristickou analýzu prováděli tři kolegové z oblasti IT. Byli předem seznámeni s testovaným systémem a scénáři testování. Podle scénářů procházeli mockup prototyp a do záznamových archů popsali každé porušení principů zmíněné heuristiky. Každý provedl dva průchody podle scénářů a na závěr ještě jeden nezávisle na scénáři. Z vyplněných záznamových archů byly do výsledného seznamu (viz níže) agregovány všechny připomínky. Každá položka byla ohodnocena stupněm závažnosti (prioritou v rozmezí 1 až 3 – zanedbatelný, marginální, závažný) a opatřena komentářem. 71
4. Návrh 1. Viditelnost stavu systému Z prototypu není jasné, jestli jsou akce systému okamžité (např. načítání seznamů) a není potřeba upozornit uživatele, že systém vykonává úlohu pomocí nějakého „progress“ indikátoru. Rovněž není jasné, zda je uživatel nějakým způsobem informován o úspěšném vykonání akcí jako např. vytvoření nebo smazání kontaktu apod. Indikátory stavu i notifikace o provedení akcí v prototypu chybí. V systému budou implementovány obě tyto funkce. – Priorita: 2 2. Shoda systému s realitou Na stránkách obchodních entit (účtů, obchodních případů atd.) je záložka jménem „komunikace“, lepším názvem by byl „chat“. Označení „účty“ je zavádějící, srozumitelnější by bylo označení „zákazníci“ nebo „firmy“. Stejně tak „Kontakty“ by mohly být pojmenovány slovem „osoby“. Záložka „komunikace“ bude přejmenována na „chat“. Názvy obchodních entit zůstanou prozatím zachovány. – Priorita: 3 3. Minimální zodpovědnost a stres – 4. Zachování konzistence a standardů Měly by být sjednoceny tlačítka v dialozích – v dialogu s upozorněním na opouštění stránky s entitou, která byla upravena, jsou tlačítka „Opustit bez uložení“ a „Zrušit“, v dialogu potvrzení smazání entity je „Zrušit“ odkazem. Dialogy budou sjednoceny. Méně významná akce bude odkazem. – Priorita: 1 5. Prevence chyb Pod některými formulářovými poli by měl být uveden formát očekávaných hodnot a omezení (např. formát telefonních čísel, omezení pro nové heslo, maximální cena). Tyto informace mohou být případně uvedeny formou tooltip nápovědy. V detailech obchodních entit (např. kontaktu) by mohla být označena povinná pole formuláře. Formát očekávaných hodnot a omezení bude k formulářovým polím přidán. Na stránkách detailů kontaktů případně jiných entit budou označena povinná formulářová pole tučným fontem. – Priorita: 2 6. Rozpoznání místo rozvzpomínání Na aktuální stránce není uvedena pozice ve stromové struktuře a odkazy na nadřazené stránky. To by mohlo být uvedeno formou breadcrumb. Tlačítka „Uložit“, „Nový“ a „Smazat“ na stránce entity by neměla být zobrazena, pokud se pohybujeme na záložkách „Komunikace“ nebo „Vazby“. Struktura aplikace není komplexní, aby uživatel nevěděl kde se nachází a potřeboval odkazy na nadřazené stránky. Tlačítka budou ve stavu „disabled“. Na prototypu to není zřetelné.
72
4.2. Výběr implementačního prostředí – Priorita: 1 7. Flexibilita a efektivita použití Uložení změn na stránkách entit by mohlo být provedeno pomocí klávesové zkratky „Ctrl+s“. Odeslání komentáře nebo odpovědi v komunikaci by mohlo být provedeno zkratkou „Shift+Enter“. Klávesová zkratka pro uložení změn není u webových aplikací standardní, nicméně tento požadavek bude navržen jako rozšiřující funkce. Zkratka pro odeslání komentáře bude implementována. – Priorita: 1 8. Estetický a minimalistický design – 9. Smysluplné chybové hlášky – 10. Nápověda a dokumentace Kontextová nápověda u seznamu produktů v obchodním případu by měla obsahovat místo popisu obsahu panelu příklady akcí, které může uživatel provést. Kontextová nápověda by mohla být uvedena na každé stránce nebo panelu, který umožňuje provedení různých akcí. Kontextové nápovědy budou přidány na stránkách entit ke všem panelům, které definují vazby na jiné entity. – Priorita: 2
4.2
Výběr implementačního prostředí
Systém bude vyvinut na platformě Java EE. Jak bylo již zmíněno, pro tento způsob vývoje existují na GAE určitá omezení, které se týkají některých komponent a webových frameworků, které buď nelze vůbec použít nebo jejich použití vyžaduje dočasné obejití v kódu (viz kapitola 1.4.2.1). Výběr technologií byl tedy omezený a obtížný. Webová vrstva aplikace bude tvořena několika frameworky. Jako webový aplikační framework byl zvolen JSF 2.1, který je Java EE standardem. Aplikační logika bude obsažena v Managed bean komponentách JSF. Prezentační vrstva bude tvořena XHTML51 stránkami a frameworkem pro tvorbu šablon stránek Facelets. Pro tvorbu prezentační vrstvy bude použita knihovna komponent pro JSF s názvem PrimeFaces verze 3.4.2. Pro vytváření srozumitelných URL52 a navigaci mezi stránkami bude použit framework PrettyFaces 3.3.3. Jako persistentní úložiště bude zvolena NoSQL objektová key-value databáze App Engine Datastore. App Engine Java SDK poskytuje pro přístup k Datastore low-level API (základní operace – get, put, delete, query). Im51 52
Extensible HyperText Markup Language Uniform Resource Locator
73
4. Návrh plementuje ale i Java EE standardy JDO a JPA, které zahrnují mechanizmy pro definici entit a dotazování. Nad low-level API existují další frameworky, které ulehčují práci s Datastore – Objectify, Twig, Slim3. Pro přístup k Datastore bude zvolen Objectify 4.0b1. Nad tímto frameworkem bude vytvořena DAO53 vrstva, která bude spolu s entitami sloužit vyšším vrstvám pro přístup k datům. Aplikační logika bude využívat i další služby, které poskytuje App Engine formou různých API. Pro odesílání emailů bude použito Mail API, pro přihlašování uživatelů Users API apod. S výběrem implementačního prostředí souvisí i výběr vývojového prostředí. Pro Java EE jich existuje hned několik. Platforma GAE ovšem poskytuje plugin pro Eclipse (Google plugin for Eclipse), který zahrnuje SDK – sadu nástrojů pro vývoj aplikací, která slouží pro vývoj a emulaci reálného prostředí GAE. Pomocí něj lze testovat aplikace lokálně nebo je nasadit přímo na App Engine. Jako IDE byl zvolen Eclipse ve verzi Juno se zmíněným pluginem.
Obrázek 4.4: Logická architektura systému
4.3 4.3.1
Architektura systému Logická architektura
Logickou architekturou je myšleno organizování softwarových tříd do balíčků (nebo jmenných prostor) subsystémů a vrstev viz Larman [26]. Název „logická“ je z toho důvodu, že nerozhoduje o tom, kde a jak jsou elementy nasazeny (na jakých fyzických zařízeních apod.). Fyzické nasazení je předmětem fyzické architektury systému. 53
74
Data Access Object
4.3. Architektura systému Logická architektura se modeluje pomocí UML diagramu balíčků (Package diagram). Obrázek 4.4 zobrazuje logickou architekturu CRM systému zasazenou do kontextu Java EE projektu, který obsahuje implementaci systému. Webové aplikace vyvíjené v Java EE mají podobnou strukturu, projekt zahrnuje dva základní balíčky – „src“, ve kterém jsou zdrojové soubory aplikace v jazyku Java a balíček „web“, který obsahuje zdroje, knihovny, konfigurační soubory, webové stránky, jejich šablony a deskriptory popisující nasazení systému. Po kompilaci a sestavení projektu jsou soubory obsahem jediného WAR54 archivu. Aplikace jsou většinou rozděleny na tři logické vrstvy – uživatelské rozhraní, doménu a technické služby viz Larman [26]. Vrstva uživatelského rozhraní je v CRM systému reprezentována balíčkem „web“ s webovými stránkami a dalšími zdroji. Doménu tvoří balíčky „Managed Beans“, „DAO“, „Entity“ a další, které obsahují Java třídy s aplikační logikou nebo rozhraním pro přístup k persistentnímu úložišti a k dalším externím službám. Obsahem vrstvy technických služeb jsou služby, které poskytuje platforma GAE jako Datastore API, Memcache API aj.
Obrázek 4.5: Fyzická architektura systému
4.3.2
Fyzická architektura
Fyzická architektura definuje infrastrukturu, na které bude systém CRM nasazen. Je zobrazena UML diagramem nasazení, který může obsahovat tři typy elementů viz Larman [26]. Zařízení (Device) je fyzický výpočetní zdroj, který poskytuje zpracování, paměťové služby a umožňuje spuštění software (např. počítač, server, mobilní zařízení). Výpočetní prostředí (Execution environment) je softwarový výpočetní zdroj (např. operační systém, virtuální stroj, webový prohlížeč, databázový stroj), který běží na nějakém vnějším uzlu (např. počítači) a poskytuje hostitelské služby pro jiné spustitelné softwarové elementy. Artefakt (Artifact) specifikuje fyzickou informaci, která je použita nebo vyprodukována procesem vývoje software nebo nějakou operací systému viz OMG UML [33]. Příkladem jsou soubory modelu, zdrojové sou54
Web Archive
75
4. Návrh bory, skripty, spustitelné soubory atd. Artefakt je zdrojem nasazen na uzel (zařízení nebo výpočetní prostředí). Uživatel bude k systému přistupovat ze stanice s webovým prohlížečem, který umožní zabezpečený přistup pomocí HTTPS55 viz obrázek 4.5. Systém CRM bude nasazen na platformu App Engine v archivačním souboru WAR. Fyzická infrastruktura platformy GAE je tvořena cloudovou infrastrukturou společnosti Google (datová centra). Distribuci zátěže systému zabezpečuje GAE pomocí „load balanceru“. K systému přistupuje v jednu chvíli několik uživatelů 4.6. Na App Enginu existuje několik paralelních instancí systému, které jsou virtuálně (zpravidla i fyzicky) umístěny na různých strojích. Load balancer má na starosti přidělení konkrétní obslužné instance CRM systému uživateli.
Obrázek 4.6: Distribuce zátěže systému na platformě GAE Pokud vzroste počet uživatelů systému, jsou vytvořeny další instance systému a tito noví uživatelé jsou obslouženi těmito novými instancemi. Klesne-li počet uživatelů, je některá instance zrušena a její uživatelé jsou přiděleni jiné instanci. Všechny instance využívají společné služby, které GAE poskytuje (Datastore, Memchace atd.).
55
76
Hypertext Transfer Protocol Secure
Kapitola
Realizace Tato kapitola popisuje realizaci systému. Je rozdělena do čtyř částí odpovídajících jednotlivým vrstvám aplikace (integrační, datová, prezentační a aplikační logika). Obsahuje popis klíčových a jiných zajímavých částí implementace.
5.1
Integrační vrstva
Integrační vrstva je tvořena službami platformy GAE [17]. Nejdůležitější z nich je Datastore, která slouží k persistenci dat. Mezi další použité patří Cron Service (spouštění naplánovaných úloh) a Users Service (autentizace uživatelů).
5.1.1
Datastore
Datastore není klasickou relační databází, ale distribuovanou NoSQL objektovou key-value databází. Z konceptuálního pohledu je Datastore hash mapa složená z klíčů k entitám a entity jsou hash mapy složené z názvů atributů a jejich hodnot. Nad Datastore lze provést pouze čtyři základní operace – put() uložení entit, delete() smazání entit, get() získání entit a query() dotazování na entity. Každá entita je identifikována tzv. klíčem Key, který se složeninou tří hodnot – názvu entity, rodiče a hodnoty id (řetězec nebo celé číslo). Entity se fyzicky ukládají a formují do struktur podobných souborovému systému, kde má každá z nich podobně jako soubor svého rodiče. Tento vztah se vytvoří při vzniku entity a je permanentní. Entita, která nemá předka je nazývána kořenovou. Entita a strom jejích potomků patří do jedné „entitní skupiny“. V rámci jedné transakce je povoleno získat data z pouze jedné takové skupiny. Je ale možno vykonávat transakce napříč více skupinami tzv. XG (cross-group) transakce. K získávání entit na základě hodnot jejich atributů se používají dotazy, které jsou provedeny nad daným typem. Mohou specifikovat filtry na hodnoty atributů, klíčů a předků. Výsledky jsou vráceny v seznamu. K určení výsledků 77
5
5. Realizace dotazů se využívají indexy, které jsou automaticky nebo manuálně tvořeny nad atributy. V systému CRM není pro přístup k Datastore použito low-level API, ale framework Objectify, který práci s Datastore v mnoha směrech usnadňuje a zpřehledňuje. Jeho specifikace a popis použití je uvedena v kapitole 5.2.1. 5.1.1.1
Fyzický datový model
Tato část popisuje transformaci konceptuálního datového modelu na fyzický datový model, čili způsob reprezentace entit, atributů a vztahů na perzistentním úložišti platformy GAE (Datastore). Datové typy atributů byly voleny podle příručky pro vývoj na GAE [17] – pro čísla jsou to int, long, float, řetězce str, db.Text, logický typ bool, datum datetime.date a reference db.Key. Vazby mezi entitami jsou řešeny několika způsoby. Kompozice jsou převedeny na entitní skupiny – entity, které jsou z konceptuálního hlediska součástmi složeného objektu, jsou v rámci entitních skupin potomky. Generalizace je řešena přidáním dvou skrytých atributů na straně potomka – hodnota diskriminátoru (název třídy) a seznam všech diskriminátorů třídy (název třídy, třídy předka atd.). Datastore umí nativně ukládat kolekce jednoduchých datových typů (včetně kolekcí klíčů Key). Tímto přístupem jsou řešeny vazby typu 1:M resp. M:N. U vazby 1:M je na straně zdrojové entity definován seznam klíčů na cílové entity. Vazba M:1 je řešena přidáním klíče cílové entity do zdrojové entity. Konkrétní řešení záleží na jednotlivých vazbách a dotazech, které jsou nad nimi prováděny. Entity spojené vazbou M:N nesou seznam klíčů na entity protější strany. Asociační třídy jsou řešeny vazební entitou.
5.1.2
Cron Service
Cron Service slouží k nastavení a spouštění naplánovaných úloh, které se vykonávají v pravidelných intervalech nebo ve stanovený čas. Tyto úlohy jsou běžně nazývány pojmem „cron jobs“. V systému existují dvě naplánované úlohy – odeslání faktur klientům (provádí se jedenkrát měsíčně) a vygenerování záznamů demo aplikace (provádí se denně). Úlohy spouští služba Cron Service automaticky tak, že ve stanovený čas přistoupí pomocí požadavku HTTP56 GET na stanovené URL. Nastavení je provedeno v souboru cron.xml viz kód 5.1. U druhé úlohy je nastaven identifikátor nasazené verze, na které je spuštěna a časová zóna. Zdrojový kód 5.1: cron.xml 1 2 3
56
78
Hypertext Transfer Protocol
5.1. Integrační vrstva 4 5 6 7 8 9 10 11 12 13 14 15
/ c r o n / s e n d I n v o i c e s Sends i n v o i c e s t o c l i e n t s e v e r y month <s c h e d u l e>2nd sunday o f month 03 : 0 0 / c r o n / generateDemo G e n e r a t e s sample data f o r demo e v e r y day <s c h e d u l e>e v e r y day 03 : 0 0 Europe / Prague v e r s i o n −2
Jelikož systém úlohy spouští přístupem na URL adresy, nechceme, aby k těmto adresám mohli přistupovat běžní uživatelé. Zabezpečení je provedeno standardním způsobem pomocí bezpečnostního omezení v souboru web.xml.
5.1.3
Users Service
Uživatel GAE aplikace může být autentizován třemi způsoby – pomocí Google Accounts, účtem z vlastní domény na Google Apps nebo OpenID identifikátory. Aplikace pozná, zda je uživatel přihlášen, může ho přesměrovat na stránku s přihlášením a rozezná jeho roli. V systému je použita autentizace pomocí Google Accounts. Ta je však omezená v tom, že rozeznává pouze dvě uživatelské role (přihlášený uživatel, administrátor). Vlastní role vytvářet nelze. Do aplikace se tedy může přihlásit jakýkoli uživatel vlastnící Google Accounts účet. Po přihlášení systém ověří, jestli se jedná o právoplatného uživatele systému – uživatele CRM (spadá pod nějakého klienta) nebo pracovníka CRM (manažera nebo administrátora), spáruje přihlašovací účet se skutečným účtem systému a přesměruje uživatele na jeho domovskou stránku (CRM home resp. Front-office). Pokud není účet nalezen je návštěvník přesměrován na demo verzi aplikace. Účty se ověřují a párují podle emailu přihlašovacího účtu, který je získán tímto kódem UserServiceFactory.getUserService().getCurrentUser().getEmail(). Je nutné rovněž specifikovat restrikce přístupu uživatelů k jednotlivých částem aplikace. To je provedeno standardní formou v deskriptoru nasazení web.xml viz kód 5.2. Název role pro pracovníka CRM je admin, pro uživatele je role označena symbolem hvězdičky. Zdrojový kód 5.2: web.xml 1 2 3 4 5 6 7 8 9 10 11
<web−app . . . > ... <s e c u r i t y −c o n s t r a i n t> <web−r e s o u r c e −c o l l e c t i o n> /crm /∗ ∗
79
5. Realizace 12 13 14 15 16 17 18 19 20 21
<s e c u r i t y −c o n s t r a i n t> <web−r e s o u r c e −c o l l e c t i o n> / admin /∗ admin ...
5.2
Datová vrstva
Vrstva přístupu k datům (resp. datová) spadá svým obsahem pod vrstvu integrační. Slouží k přístupu a manipulaci s daty, které jsou uloženy na persistentním úložišti (Datastore). Je navržena pomocí J2EE vzoru „Generic DAO“ [4] a GoF57 vzoru „Abstract Factory“ [12]. K její realizaci je použit framework Objectify.
5.2.1
Objectify
Objectify [43] je Java API, které slouží pro přístup k Datastore platformy GAE. Je praktičtější alternativou k low-level API a použitelnější než JDO nebo JPA. Umožňuje ukládání, mazání, získávání a dotazování nad objekty vlastních typů. Zahrnuje všechny nativní vlastnosti Datastore. Poskytuje typově bezpečné a jednoduché dotazování. Automaticky ukládá data do cache paměti. Podporuje polymorfizmus, má jednoduchý transakční model, není závislý na jiných knihovnách a má kvalitní dokumentaci. Framework Objectify byl použit při definici entitních tříd a operací, které slouží k manipulaci s daty. Pro jeho použití bylo nutno do projektu přidat knihovnu objectify-4.0.jar, odebrat geronimo-jpa_3.0.jar a nastavit filtr v souboru web.xml. 5.2.1.1
Entity a relace
Entita je objekt, který nese hodnoty dat uložených v databázi a odpovídá jedné definované POJO58 třídě. V rámci Datastore je entita objektem v hash mapě, na který je odkazováno pomocí klíče. Každá entita musí být opatřena anotací @Entity frameworku Objectify a registrována, aby mohl být při spuštění aplikace vytvořen metamodel entit sloužící k efektivní manipulaci s daty. Registrace je provedena ve třídě ObjectifyDaoFactory.java (viz kód 5.7). Pokud je entita potomkem jiné entity, značí se anotací @EntitySubclass viz kód 5.3 řádek 3. K tomu, aby správně fungoval polymorfizmus, musíme zapnout indexování index=true. 57 58
80
Gang of Four Plain Old Java Object
5.2. Datová vrstva V každé entitě musí být označen jeden atribut anotací @Id, jehož hodnota slouží k tvorbě klíče a identifikaci. Relace jsou řešeny prostřednictvím klíčů, které jsou uloženy jako hodnoty atributů entit. Existuje několik variant jejich definování. Použita je buď generická verze Key nebo Ref. Z hlediska způsobu uložení v Datastore jsou oba způsoby identické. Verze Ref navíc umožňuje uchování reference na instanci jiné entity. Aby byla při načítání entity inicializována i odkazovaná entita, je nutné uvést anotaci @Load viz kód 5.3 řádek 12. Následně se reference zapouzdřuje do „getter“ a „setter“ metod. Vazba na seznam aktivit je realizována seznamem klíčů aktivit List>. Zdrojový kód 5.3: Contact.java 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
import com . g o o g l e c o d e . o b j e c t i f y . a n n o t a t i o n . ∗ ; @ E n t i t y S u b c l a s s ( i n d e x=true ) public c l a s s Contact extends B u s i n e s s C a s e { //@Id Long i d ; // i d d e f i n e d i n s u p e r c l a s s String email ; String firstName ; S t r i n g lastName ; GenderType g e n d e r ; L i s t > a c t i v i t i e s = A r r a y L i s t >() ; @Load Ref c a t ; ... public C o n t a c t C a t e g o r y ge tC at ( ) { return c a t . g e t ( ) ; } public void s e t C a t ( C o n t a c t C a t e g o r y c ) { c a t = Ref . c r e a t e ( c ) ; } }
5.2.1.2
Operace a dotazy
Všechny příkazy pro manipulaci s daty jsou provedeny pomocí instance Objectify, která drží perzistentní kontext. Existuje několik způsobů jak načítat, ukládat a mazat entity. V kódu 5.4 jsou uvedeny nejpoužívanější. Dotazy pro načítání dat mohou obsahovat filtry, ve kterých se mohou používat relační operátory. Složitější manipulace s daty se provádí transakcemi. Zdrojový kód 5.4: Operace a dotazy 1 2 3 4 5 6 7 8 9 10 11 12 13
// g e t e n t i t y by i t s i d Contact c1 = o f y ( ) . l o a d ( ) . t y p e ( Contact . c l a s s ) . i d ( 1 2 3L) . g e t ( ) ; // g e t l i s t o f e n t i t i e s L i s t c s = o f y ( ) . l o a d ( ) . t y p e ( Contact . c l a s s ) . f i l t e r ( " g e n d e r " , GenderType .MALE) . l i s t ( ) ; // g e t f i r s t e n t i t y o f a r e s u l t l i s t Contact c2 = o f y ( ) . l o a d ( ) . t y p e ( Contact . c l a s s ) . f i l t e r ( " lastName " , "Wong" ) . f i l t e r ( " f i r s t N a m e ␣ != " , " Wai " ) . f i r s t ( ) . g e t ( ) ; // s a v e e n t i t y o f y ( ) . s a v e ( ) . e n t i t y ( c1 ) . now ( ) ; // d e t e l e e n t i t i e s o f y ( ) . d e l e t e ( ) . e n t i t i e s ( c1 , c2 ) . now ( ) ;
81
5. Realizace
5.2.2
Data Access Object
Data Access Object (DAO) je návrhovým vzorem z Core J2EE Pattern katalogu [27]. Slouží k abstrakci a zapouzdření přístupu k datovým zdrojům a správě spojení k nim. Motivací k použití tohoto vzoru je oddělení aplikační logiky od konkrétní realizace mechanizmů pro perzistenci dat. Existuje několik strategií pro jeho konkrétní použití viz Bien [4]. Já jsem zvolil generické DAO v kombinaci s doménově specifickým.
Obrázek 5.1: Diagram tříd – datová vrstva Generické DAO je obecné rozhraní, které definuje předpisy metod sloužících k základní manipulaci s daty. Není závislé na frameworku Objectify, může být implementováno i jinými frameworky a přístupy (např. pomocí GAE low-level API). Je generické, definuje parametrizovaný typ T, který je v době použití kódu nahrazen některou entitou (viz GenericDao.java kód 5.5). Toto rozhraní je implementováno pomocí frameworku Objectify ve třídě ObejctifyGenericDao.java, ze které následně dědí konkrétní DAO třídy (např. ObjectifyContactDao.java viz diagram 5.1). Zdrojový kód 5.5: GenericDao.java 1 2 3 4 5 6 7 8 9 10 11
public i n t e r f a c e GenericDAO { T s a v e (T e n t i t y ) ; T s a v e A l l ( I t e r a b l e e n t i t i e s ) ; T g e t E n t i t y ( Long i d ) ; T g e t E n t i t y B y P r o p s (Map<S t r i n g , Object> p r o p e r t i e s ) ; C o l l e c t i o n g e t L i s t ( ) ; C o l l e c t i o n g e t L i s t B y P r o p s (Map<S t r i n g , Object> p r o p e r t i e s ) ; void d e l e t e (T e n t i t y ) ; void d e l e t e A l l ( I t e r a b l e e n t i t i e s ) ; ... }
Pro každou entitu je vytvořen zvláštní DAO objekt. Ten může kromě metod z generického DAO implementovat i jiné metody, které jsou zpravidla 82
5.2. Datová vrstva definovány v příslušném rozhraní. Například v ContactDao.java je definován předpis pro metodu getContactsEmployers(), která slouží k získání všech zaměstnavatelů osoby a je specifická pro danou entitu.
5.2.3
Abstract Factory
Je-li možné, že dojde ke změně způsobu uložení dat (jiná databáze) nebo přístupu k nim (jiný framework), je vhodné pro DAO vrstvu implementovat vzor „Abstract Factory“ [27]. Tato strategie poskytuje abstraktní třídu, která má na starosti konstrukci konkrétních továrních tříd, pomocí nichž jsou vytvořeny skupiny DAO objektů viz diagram 5.1. V celé aplikaci smí existovat pouze jedna instance pro přístup k datovému zdroji, proto je ve třídě DaoFactory.java použit návrhový vzor „Singleton“ viz kód 5.6, který toto chování zajišťuje. Zdrojový kód 5.6: DaoFactory.java 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
public abstract c l a s s DaoFactory { private s t a t i c DaoFactory i n s t a n c e = n u l l ; public s t a t i c DaoFactory g e t I n s t a n c e ( ) { i f ( i n s t a n c e == n u l l ) { i n s t a n c e = new O b j e c t i f y D a o F a c t o r y ( ) ; } return i n s t a n c e ; } public s t a t i c void s e t I n s t a n c e ( DaoFactory i n s t a n c e ) { DaoFactory . i n s t a n c e = i n s t a n c e ; } public abstract AccountDao getAccountDao ( ) ; public abstract ContactDao getContactDao ( ) ; ... }
V konkrétních továrnách je většinou nastaveno spojení s databází nebo jiná konfigurace a jsou implementovány metody pro přístup ke konkrétním DAO objektům. V továrně ObjectifyDaoFactory.java je například provedena navíc registrace entitních tříd pro framework Objectify viz kód 5.7. Zdrojový kód 5.7: ObjectifyDaoFactory.java 1 2 3 4 5 6 7 8 9 10 11 12
public c l a s s O b j e c t i f y D a o F a c t o r y extends DaoFactory { static { O b j e c t i f y S e r v i c e . r e g i s t e r ( Account . c l a s s ) ; O b j e c t i f y S e r v i c e . r e g i s t e r ( Contact . c l a s s ) ; ... } @Override public ContactDao getContactDao ( ) { return new O b j e c t i f y C o n t a c t D a o ( ) ; } ... }
83
5. Realizace
5.3
Prezentační vrstva
Prezentační vrstva systému je tvořena XHTML webovými stránkami frameworku JSF, šablonami webových stránek deklaračního jazyka Facelets, komponentami knihovny PrimeFaces a dalšími zdroji jako jsou CSS59 kaskádové styly, skripty v jazyku JavaScript a obrázky.
5.3.1
JavaServer Faces
Komponentový framework JSF je standardem pro vývoj prezentační vrstvy webových aplikací na platformě Java EE viz Jendrock [21]. Skládá se ze dvou částí. První je API, které slouží pro reprezentaci komponent a správu jejich stavu, obsluhu událostí, validaci a konverzi dat, definici navigace mezi stránkami, podporu internacionalizace a přístupnosti a rozšiřitelnost těchto funkcí. Druhou je knihovna tagů reprezentující komponenty, které mohou být umístěny na webové stránky a spojeny s objekty na serveru. JSF aplikace je standardní webová apli- Obrázek 5.2: Architektura JSF kace, která na serveru zpracovává HTTP po- (zdroj: Goncalves [15]) žadavky klienta a produkuje HTML stránky, které klientovi odesílá jako odpověď viz Goncalves [15]. Framework JSF je stejně jako většina webových frameworků založen na návrhovém vzoru MVC60 , který odděluje view (stránky) od modelu (dat, které stránky zobrazují). Kontroler obsluhuje akce uživatele, které mění model a na základě toho je aktualizováno view (pohledy). U frameworku JSF je kontrolerem servlet s názvem FacesServlet (viz obrázek 5.2), který vyhodnocuje požadavky a volá akce nad modelem pomocí „managed bean“ komponent. Servlet se konfiguruje ve faces-config.xml souboru nebo od verze JSF 2.0 anotacemi v Java třídách ( „managed beanách“, konvertorech, komponentách a validátorech). Stránky tvořící view mohou být definovány v různých deklaračních jazycích (JSP, XHTML). Od verze JSF 2.0 se pro deklaraci stránek a komponent standardně používá Facelets (XHTML stránky, ve kterých jsou pro zobrazení komponent použity JSF tagy). Renderer slouží pro vykreslování komponent a překlad vstupu uživatele na hodnoty komponent. Validátory jsou komponenty, které ověřují správnost vstupních hodnot uživatele. Konvertory převádějí hodnoty objektů na řetězce, které je možno na stránkách zobrazit a naopak. Konfigurační soubor faces-config.xml se nachází v projektu ve složce ../war/WEB-INF. Obsahuje pouze nastavení lokalizace. Ostatní nastavení je 59 60
84
Cascading Style Sheets Model–view–controller
5.3. Prezentační vrstva provedeno anotacemi přímo v „managed beanách“. Popis managed bean komponent je součástí kapitoly „aplikační logika“ 5.4.1. 5.3.1.1
Facelets
Deklarační jazyk Facelets slouží k tvorbě prezentační vrstvy JSF aplikací, je součástí JSF specifikace a náhradou za JSP. Důležitým rozšířením je podpora pro tvorbu šablon. Formátem stránek je XHTML, který je postaven na standardu XML. V kódu stránek jsou deklarovány jmenné prostory různých knihoven tagů, které slouží k definici komponent. Existuje několik standardních knihoven, jež mohou být na stránky přidány. Nejčastěji to jsou knihovny pro tvorbu šablon (JSF Facelets Tag Library, prefix ui:), pro definici UI komponent (JSF HTML Tag Library, prefix h:) a pro obsluhu akcí (JSF Core Tag Library, prefix f:). Je podporována i tvorba vlastních komponent a knihoven komponent, pro které se vytváří vlastní prefix. Komponenty deklarované pomocí tagů na stránkách mohou být asociovány s metodami a vlastnostmi v Java třídách ( „managed beanách“) pomocí výrazů zapsaných v jazyce EL61 . Zdrojový kód 5.8 zobrazuje fragment šablony CRM aplikace. V šabloně jsou deklarovány jmenné prostory pro všechny použité knihovny tagů. Dále obsahuje komponenty popisující layout aplikace. Element definuje místo v šabloně, na které je možno vložit obsah elementu umístěného ve stránkách, které šablonu používají. Zdrojový kód 5.8: appTemplate.xhtml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
< !DOCTYPE HTML PUBLIC " −//W3C//DTD␣HTML␣ 4 . 0 1 ␣ T r a n s i t i o n a l //EN" " h t t p : // www. w3 . o r g /TR/ html4 / l o o s e . dtd "> ... ...
< u i : i n s e r t name=" c o n t e n t "> [ c o n t e n t ] ...
Šablona je použita například v kódu 5.9. V klientské stránce je element . Jeho atribut template slouží k definici jména šablony. 61
Expression Language
85
5. Realizace Následuje element , jehož obsah se vloží do šablony na místo označené elementem . Ze standardních UI komponent je v uvedeném fragmentu pouze element reprezentující formulář. Ostatní komponenty (s prefixem p:) jsou z frameworku PrimeFaces. Spojení UI komponenty s objektem v managed beaně, který využívá zápis v EL je například na řádce 13, kde je pro tabulku v atributu value definován datový zdroj (seznam kontaktů – contactList) EL zápisem value=”{#contactBean.contactList}”. Na managed beaně s názvem contactBean (viz kód 5.10) je zavolán příslušný „getter“ – metoda getContactList(), která vrací daný seznam.
5.3.2
PrimeFaces
PrimeFaces je open source knihovna komponent pro JSF s mnoha rozšířeními a vlastnostmi. Sada komponent PrimeFaces obsahuje vedle standardních komponent (inputText, commandButton, dataTable, column aj.) i velmi pokročilé komponenty jako jsou např. HTML editor, dialog (modální okno), autocomplete (podpora automatického dokončování resp. napovídání textu), kalendář, grafy nebo myšlenkové mapy. V PrimeFaces je zabudován AJAX62 , který je založen na standardním JSF 2.0 AJAX API a využívá knihovnu jQuery63 . Pro použití PrimeFaces stačí do projektu přidat pouze jednu knihovnu formátu JAR. Tato knihovna není závislá na jiných knihovnách a pro její použití není potřeba žádné další konfigurace. Pro vývoj systému byla použita verze PrimeFaces 3.4. K tomu, aby bylo možné komponenty používat, je nutné ve jmenných prostorech XHTML stránek deklarovat příslušnou knihovnu tagů (viz kód 5.9, řádek 5). Komponenty knihovny PrimeFaces bývají zpravidla uvozeny p: prefixem. Ve fragmentu kódu 5.9 je jich použito hned několik. Na řádku 8 je sloužící pro zobrazení notifikace, která po šesti sekundách automaticky zmizí. Hned pod ním je použit panel , který ohraničuje a seskupuje vnořené prvky. Další komponentou je tabulka , ve které jsou zobrazeny prvky seznamu. Seznam, který má být zobrazen, je získán z přidružené managed beany a musí být instancí třídy java.util.Collection nebo jejího potomka, zde je to List (viz kód 5.10, řádek 5). Třída Contact.java je jednou z entit systému. Tabulka obsahuje několik dalších nastavení viz příručka PrimeFaces [8]. Sloupce tabulky jsou definovány elementem , který svými atributy nastavuje řazení a filtrování nad celou tabulkou. Důležitou komponentou je modální okno , které se vyvolá po stisku odkazu (viz řádek 22) javascriptovou akcí oncomplete="delDialog.show()". 62
AJAX (Asynchronous JavaScript and XML) je technologie vývoje interaktivních webových aplikací, u kterých se dynamicky mění obsah stránek a není nutné ho opětovně načítat. Využívá technologie (X)HTML, CSS, DOM, JavaScript, XMLHttpRequest. 63 jQuery je javascriptová knihovna určená pro skriptování HTML na straně klienta.
86
5.4. Aplikační logika Zdrojový kód 5.9: contactList.xhtml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33
< u i : d e f i n e name=" c o n t e n t ">