1 České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů Diplomová práce Volný software na podporu firemních procesů Bc. Pavel...
České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů
Diplomová práce
Volný software na podporu firemních procesů Bc. Pavel Richter
Vedoucí práce: Ing. Lukáš Zikmund
Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika 4. ledna 2010
iv
v
Poděkování Na tomto místě bych chtěl poděkovat své rodině za podporu při studiu a tvorbě diplomové práce, vedoucímu práce Ing. Lukáši Zikmundovi za podnětné připomínky a vedení práce a všem pracovníkům společnosti ÚVT, s.r.o. za spolupráci při vytváření projektu.
vi
vii
Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).
Abstract The thesis deals with the design and implementation of system for business processes support. When finished, the application developed will be released for free use. It will provide brand new system for my employer, but it would become an alternative for start-up companies too. During the development I aimed to keep the code well arranged, based on modularity and existing frameworks. All used components are free of charge (usually provided under GPL) and do not require additional costs.
Abstrakt Diplomová práce se zabývá návrhem a implementací systému pro podporu firemních procesů, který bude po dokončení uvolněn pro volné použití. Umožní tak náhradu stávajícího informačního systému firmy a poskytne alternativu začínajícím společnostem. Vývoj byl založen na přehlednosti, modularitě a zapojení existujících služeb. Použité komponenty jsou dostupné pro volné použití a nevyžadují dodatečné náklady.
B Instalační a uživatelská příručka B.1 Instalační příručka . . . . . . . . . . . B.1.1 Co je potřeba pro běh aplikace B.1.2 Instalace aplikace . . . . . . . . B.2 Uživatelská příručka . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
55 56 56 56 56
OBSAH
xiii
C Obsah přiloženého DVD
57
xiv
OBSAH
Seznam obrázků 3.1 3.2 3.3 3.4
Princip modularity aplikace . . . . . . . Uživatelské rozhraní zakázky v systému Uživatelské rozhraní zakázky v systému Komunikační okna chatu . . . . . . . . .
Přihlašovací proces - start . . . . . . . . . . . . . Přihlašovací proces - po potvrzení jména . . . . . Přihlašovací proces - po zadání hesla . . . . . . . Uživatelské rozhraní aplikace . . . . . . . . . . . URL adresa a řízení aplikace . . . . . . . . . . . . Interaktivní mapa - využití Google Maps API . . Centrální vyhledávací prvek je umístěn v hlavičce Interaktivní panel uživatelů . . . . . . . . . . . . Interaktivní panel uživatelů - nabídka akcí . . . . Panel uživatelů a jeho nastavení . . . . . . . . . . Horizontální menu webové aplikace Opentis . . . ER model systému ukládání kontakních údajů . . ER model vztahů zakázek a komentářů . . . . . . Detail uživatelského rozhraní modulu zakázek . . Detail uživatelského rozhraní dokumentů zakázky
5.1 5.2
Panel uživatelů slouží i jako lokální menu daného uživatele . . . . . . . . . . . 40 Horizontální menu webové aplikace Opentis . . . . . . . . . . . . . . . . . . . 41
6.1 6.2 6.3
Ukázka rozhraní aplikace Feng Office - zdroj: http://www.fengoffice.com . . . 43 Nabídka součástí z balíku Zoho služeb - zdroj: http://www.zoho.com . . . . . 45 Logo spojených aplikací balíku Google Apps - zdroj: http://www.google.com/apps/ 46
Úvod Tato diplomová práce se zabývá návrhem a implementací volně šiřitelné aplikace na podporu firemních procesů. Každá moderní společnost v průběhu svého fungování dříve nebo později zjistí, že jí přestávají stačit lokální kontakty poštovních klientů a úkolování zaměstnanců prostřednictvím emailového systému je nedostatečné. Také že stávající informační systémy se víc zabývají účetnictvím než ekonomickými přehledy, adresářová struktura na souborovém serveru už bují do obřích rozměrů a stává se méně a méně přehlednou, byla-li vůbec někdy. V jedné chvíli je rozhodnuto, že je třeba informačnímu chaosu udělat přítrž a nastolit pořádek. Začne hledání pořádného informačního systému. Takový systém si společnost buď pořídí kompletně od nějakého výrobce nebo si jej nechá postavit na míru. V prvním případě, pravděpodobně po náročném výběru, získává finančně nákladný systém, který ji nutí akceptovat názvosloví a logiku výrobce, grafický výstup, rozvržení obrazovky atd. Je ale pravděpodobné, že získá kompaktní systém, který toho už hodně umí a je po zaškolení personálu takřka ihned použitelný. V druhém případě musí společnost nejprve provést detailní analýzu vlastních potřeb, sehnat dobrého programátora a pak se pustí do dlouhého vývoje s nejasným koncem. Pokud bude mít trochu štěstí, získává tak produkt, který přesně charakterizuje firemní procesy a pokud nedojde k rozvázání spolupráce s výrobcem, i obrovskou flexibilitu v úpravách, nových modulech či jen datových výstupech. Obě cesty jsou velice trnité, ale po zkušenostech nabraných z mého okolí a asi nejvíce z mého současného zaměstnání, si myslím, že flexibilita a přesnost je výhodnější než rigidní informační systémy zavedených společností. Cílem mé diplomové práce je tedy tvorba modulárního informačního systému, který se může stát základem pro výměnu informací uvnitř společnosti. Jeho vnitřní procesy by měly být dostatečně obecné, aby při implementaci nebylo třeba měnit zavedené firemní činnosti a terminologie a naopak bude natolik konkrétní, aby nebránil rychlému nasazení do praxe. Tímto krokem se pokouším propojit oba dva výše zmiňované případy, tzn. systém psaný na míru vytvářím tak, aby se snadno stal podkladem pro podobný systém jiné společnosti. Při jeho tvorbě používám nejmodernější technologie k dosažení maximální použitelnosti, dostupnosti, ovládání, jednoduché správy, rozšiřování atd.
1
2
KAPITOLA 1. ÚVOD
V obsahu diplomové práce nejprve analyzuji, co moderní webová aplikace vyžaduje, dále analyzuji potřeby firemních procesů. Nasbírané poznatky poté využívám při implementaci zdrojového kódu aplikace. Velkým úspěchem a mým tajným přáním je, aby se hotová aplikace stala volně dostupným řešením pro malé a střední firmy, ale i pro úplně začínající společnosti, skupiny nebo sdružení.
Kapitola 2
Popis problému, specifikace cíle 2.1
Současný stav problému
Společnost ÚVT, s.r.o., kde jsem v současné době zaměstnancem, je typickým zastáncem vlastního řešení informačního systému. Jejich informační systém se vyvíjí už více než 10 let. Začal převodem jedné tabulky v programu Microsoft Excel do podoby webové stránky a dnes úkoluje zaměstnance, eviduje práci, vystavuje faktury, podává detailní ekonomické analýzy atd. Nezastává ale funkci účetnictví, to se zpracovává odděleně v certifikovaném programu. Potřebná data se mezi aplikacemi synchronizují. Ovšem za dlouhé roky vývoje a častými úpravami od různých programátorů se systém stává hůře udržovatelný a rozšiřitelný. Jeho obrovskou předností však je, že doposud stále funguje a v mém případě ho lze použít jako vynikající a hlavně kompletní analýzu. V rámci mé diplomové práce vyvíjím novou a moderní webovou aplikaci a chci poskytnout toto řešení pro firmy nebo skupiny, které takové řešení hledají. Aplikace bude založena na produktech s otevřeným zdrojovým kódem.
2.2
Vymezení cílů a požadavků diplomové práce
• funkční požadavky moderní webové aplikace • analýza firemních potřeb a procesů, zobecnění • implementace webové aplikace • testování • konkurence a srovnání • zhodnocení • závěr a možnosti rozšiřování aplikace
3
4
KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE
Kapitola 3
Analýza a návrh řešení Síť Internet je dnes natolik rozšířená, že se stává platformou pro běh webových aplikací, díky kterým mohou lidé spolupracovat v reálném čase bez ohledu na to, kde se právě nacházejí. Toto dynamické prostředí je ideálním místem pro kolaborativní aplikace firem, protože jsou dostupné kdekoli, kde je internetové pokrytí nebo pokrytí mobilních sítí. Mobilní přístup k Internetu je na vzestupu a lze očekávat, že v budoucnosti tomu nebude jinak. K přístupu do takové interaktivní aplikace je možné použít celou řadu zařízení i softwaru. Pro vývoj interaktivních aplikací dnes existuje mnoho vhodných platforem a programovacích jazyků. Dnes kraluje dynamickým aplikacím skriptovací jazyk PHP, který nemá zatím větší konkurenci a pokrývá majoritní světový podíl. Distribuce skriptovacího jazyka PHP jsou zcela zdarma pro všechny platformy a jeho vývoj stále pokračuje. Řešení mé webové aplikace pro podporu firemních procesů bude vycházet z obecných potřeb webových aplikací, firemních procesů a jejich realizace pomocí jednotlivých modulů. Webová aplikace [3] je v softwarovém inženýrství aplikace poskytovaná uživatelům z webového serveru skrz interní vnitropodnikovou síť nebo celosvětovou síť Internet. Klientem je klasický internetový prohlížeč, který dokáže interpretovat odpovědi webového serveru. Tomuto systému říkáme tenký klient/server.
3.1
Analýza funkčních požadavků moderní webové aplikace
Webové aplikace dnešní doby poskytují velký rozsah služeb, od emailových klientů přes internetové obchody až například k důležitým aplikacím typu informační systém banky či dnes již rozšířené online bankovnictví. Mezi moderními webovými aplikacemi nalezneme mnoho společných rysů.
3.1.1
Struktura aplikace
Struktura nebo jinak řečeno architektura aplikace označuje stav, jakým je systém vytvořen uvnitř. Vnitřní struktura systému a jeho základní vlastnosti do velké míry ovlivňuje způsob jeho možného použití. Strukturu aplikace můžeme demonstrovat na několika pojmech:
5
6
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
• rozdělení do určitých logických celků, kterým se říká komponenty • způsob práce s aplikačními daty • přenos aplikačních dat mezi komponentami nebo jádrem a komponentami Počáteční volba struktury dané aplikace je velice důležitá, je totiž základním kamenem celé aplikace. Já jsem zvolil vývojový model MVC, což je zkratka pro Model-View-Controller. V principu odděluje datový model (zkráceně model), rozhraní vhodné pro uživatele (pohled) a řídící systém (řadič). Je výhodný, protože jsou tyto komponenty odděleny tak, že můžeme modifikovat pouze jednu část. Jak probíhá cyklus aplikace se pokusím vysvětlit na příkladu: 1) uživatel provede nějakou akci, například stiskne tlačítko pro založení nového projektu 2) řadič se dozví o této akci a prostřednictvím modelu provede potřebné akce (například zápis v databázi) 3) pohled použije model a pošle aktuální data webovému prohlížeči k vykreslení (nový projekt) 4) uživatel může provádět další akci
3.1.2
Modularita aplikace
Většina webových aplikací poskytuje ve svém obsahu více logických částí, které je dobré oddělit do tzn. modulů. Je to samostatná část aplikace, která reprezentuje logicky související obsah. Moduly jsou na sobě nezávislé, ale pomohou spolu komunikovat pomocí definovaných rozhraní. Podívejte se na [2]. Tento způsob tvorby aplikace poskytuje mnoho pozitiv: • členění - rozsáhlý kód je rozdělen do samostatných bloků, což zlepšuje čitelnost i přehlednost • jednoduché přidávání nebo odebírání funkčnosti - modul lze do aplikace přidat nebo z aplikace odstranit • znovupoužitelnost - dobře vytvořený modul lze použít v jiných aplikacích • spolupráce - při týmovém vývoji může každý programátor pracovat na jiném modulu Představme si internetový obchod, kde uživatel může například procházet zboží, upravovat svůj uživatelský účet, zobrazit předešlé objednávky, zobrazit aktuální zboží v košíku atd. Navenek se aplikace jeví jako jeden celek, ale uvnitř jsou tyto jednotlivé části rozděleny do modulů. Tyto moduly mohou komunikovat mezi sebou a komunikují také s datábazovou vrstvou, ze které načítají nebo naopak, kam ukládají uživatelská a aplikační data.
3.1. ANALÝZA FUNKČNÍCH POŽADAVKŮ MODERNÍ WEBOVÉ APLIKACE
7
Obrázek 3.1: Princip modularity aplikace
3.1.3
Uživatelé a autentizace
Každá aplikace, která pracuje s jednotlivými uživateli musí pro jejich jednoznačnou identifikaci použít nějaký druh autentizace. Jinými slovy musí ověřit identitu uživatele, který se pokouší do aplikace přihlásit. Autentizace uživatele se může provést několika způsoby: • na základě znalosti uživatelského jména a hesla • na základě poskytnutí osobního klíče nebo souboru • na základě akceptování autentizace z hierarchicky vyššího systému Naprostá většina aplikací využívá autentizaci na základě ověření vloženého uživatelského jména a hesla. Tento způsob je poměrně snadno implementovatelný a dostatečně bezpečný. Předpokládáme ovšem, že používaná hesla budou dostatečně silná. Aby bylo heslo silné, musí dodržet základní pravidla: • musí mít určitý minimální počet znaků, většinou 8 až 10 • nesmí být tvořeno pouze triviálními slovníkovými výrazy • mělo by obsahovat číslice, symboly nebo velká písmena, případně kombinace • nesmí mít významovou souvislost s uživatelem - datum narození, jména rodinných příslušníků atd. Princip spočívá v odeslání klasického webového formuláře metodou POST tak, aby zadané údaje nebyly viditelné v adresním řádku prohlížeče. Kdyby byl formulář odeslán metodou GET, uživatelské údaje se uloží do historie internetového prohlížeče a můžou být zaznamenány i na dalších místech.
8
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
3.1.3.1
Bezpečná úschova hesel
Uživatelská hesla jsou ukládána v datovém uložišti, nejčastěji databázi. Aby aplikace byla bezpečná, nestačí pouze zabezpečení ze strany klienta, ale je nutné věnovat úsilí i bezpečnosti na straně serveru. Datové uložiště musí být chráněno softwarově (přístup pouze s administrátorským oprávněním) i fyzicky (kontrolovaný vstup do serverovny). Uživatelská hesla se do databáze neukládají v čitelné podobě, ale jsou pomocí hashovací funkce upraveny a až poté uloženy. Pokud by se do databáze přes zabezpečení dostala nepovolaná osoba, nemůže si hesla snadno přečíst. 3.1.3.2
Centrální ověřovací identita
Ideálním stavem je vytvoření jediné centrální ověřovací identity pro celou firmu. To může být například LDAP server nebo Active Directory pro použití v prostředí systému Microsoft Windows. Tato ověřovací identita provádí všechny potřebné autentizační operace a zvyšuje tak bezpečnost uvnitř firmy. Na druhou stranu jsou potom všechny aplikace závislé na tomto centrálním bodě.
3.1.4
Uživatelské skupiny a práva
Ve chvíli, kdy má firma více zaměstnanců, je nutné vyřešit otázku ochrany přístupu k informacím a omezení povolených akcí v rámci systému. Je možné to řešit uživatelskými skupinami nebo systémem práv, případně kombinací. Administrátor systému může jednotlivé uživatele rozdělit do vytvořených uživatelských skupin. Tímto rozdělením určí, kdo má oprávnění k jakým operacím. Například uživatelé přiřazení do uživatelské skupiny "skladníci" budou moci jediní pracovat v modulu Sklad apod. Druhý přístup se opírá o jednotlivá práva. Administrátor definuje taková práva, která chce v aplikaci spravovat. Poté stačí k jednotlivým pravidlům přidělit uživatele. Například právo "prohlížení skladu" může být nastaveno všem, právo "operace ve skladu" pouze vybraným uživatelům.
3.1.5
Komunikace uživatelů
Pokud webovou aplikaci používá více uživatelů je přirozené, že spolu chtějí navzájem komunikovat. Webové aplikace to většinou řeší vnitřními soukromými zprávami (tedy formou uživatel - uživatel) nebo veřejnou diskuzí (formou uživatel - všichni ostatní). Zaměstnanci firem často používají ke komunikaci externí programy, například Skype, ICQ nebo Jabber. Mohou ale nastat situace, kdy nemá zaměstnanec tyto programy aktuálně k dispozici, a proto se přítomnost interního komunikačního systému může hodit.
3.1.6
Zabezpečení
Zabezpečení aplikace má několik úrovní. • bezpečnost hardwaru
3.1. ANALÝZA FUNKČNÍCH POŽADAVKŮ MODERNÍ WEBOVÉ APLIKACE
9
• bezpečnost operačního systému • bezpečnost síťového přenosu 3.1.6.1
Bezpečnost hardwaru
Jak sem již zmínil v sekci Bezpečná úschova hesel, je nutné nejprve zabezpečit samotný server před neoprávněným přístupem. V případě, že pro hostování aplikace používáme cizí serverovnu, je většinou bezpečnost zaručena provozovatelem. V případě, že využíváme server svůj, musíme bezpečnost zaručit sami. 3.1.6.2
Bezpečnost operačního systému
Použitý operační systém je dobré udržovat aktuální, případně instalovat vydávané záplaty či opravy. V dnešní době je nutností mít správně nakonfigurovaný firewall. 3.1.6.3
Bezpečnost síťového přenosu
Síťový přenos dat lze chránit pomocí nadstavby základního HTTP protokolu, který se nazývá HTTPS. Protokol HTTPS běží nad protokolem HTTP, ale data jsou šifrována pomocí SSL nebo TLS. Spojení mezi klientem a serverem je tak zabezpečené proti odposlechu, podvržení.
3.1.7
Sledování událostí
V ideálním světě aplikace fungují bezchybně a uživatelé používají aplikaci pouze tak, jak bylo určeno. S reálném světě obsahuje každá aplikace několik chyb a někteří uživatelé se snaží aplikaci upravovat a jinak nabourávat. Je proto nutné udržovat soubor informací o tom, kdy se stala jaká událost a co k ní vedlo. Webové aplikace vytvářejí logovací soubory, zkráceně logy, které zaznamenávají veškerý provoz dané aplikace a umožňuje tak správcům nahlédnout do vnitřního stavu aplikace, pokud všechno nejde hladce. Není možné vždy stoprocentně určit, jak k selhání aplikace došlo, ale logovací soubory jsou důležitým prvkem monitorování provozu.
3.1.8
Synchronizace s mobilními zařízeními
Obecný úkol synchronizace mobilních zařízení s informacemi uloženými v aplikaci je značně těžký úkol. Je to dáno zejména tím, že každý uživatel má jiný mobilní telefon, jiné PDA zařízení. Navíc existuje mnoho mobilních operačních systémů a aplikací pro ně vytvořených. Kompletní analýza takového úkolu by mohla být zpracována jako samostatná práce, protože její rozsah je obrovský. Pro správnou synchronizaci musí mobilní zařízení mít ve své paměti aplikaci, která to dovolí. Takové aplikace jsou ale často komerční a tedy zpoplatněné. Realizace synchronizace může probíhat díky synchronizačnímu standardu SyncML (Synchronization Markup Language). Jak se lze dočíst v [10], účelem SyncML je nabídnout otevřený standard, který by mohl nahradit stávající synchronizační řešení, která jsou závislá na mnoha parametrech.
10
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Pro účely mé práce je řešení otázky synchronizace údajů příliš rozsáhlé a neshoduje se s hlavním zaměřením.
3.2
Analýza informačního systému společnosti
Každá společnost je svým způsobem unikátní. I když existuje mnoho metodik řízení, žádná firma je striktně nedodržuje a upravuje nebo stanovuje si je podle sebe. Proto má analýza nejvíce odpovídá procesům společnosti ÚVT, ale bude jistě podobná mnoha dalším. Zde jsou základním středobodem klienti a jejich zakázky. Klientem je v jejich případě kdokoliv, kdo s nimi vstoupí do obchodního vztahu a zakázkou je zadání (úkol, činnost), které je potřeba vykonat. Ostatní části jako je například sklad, fakturace nebo ekonomické přehledy vypadají samostatně, ale jsou ve své podstatě vždy navázány na klienty a jejich zakázky. Protože kompletní analýza zaběhlé společnosti výrazně překračuje rámec této diplomové práce, popisuji dále jen nejpodstatnější části a i ty pouze zkrácenou formou.
3.2.1
Zakázky a úkoly
Asi nejdůležitější věcí pro fungování společnosti je přehled práce. Tedy kdo a co má udělat, pokud to udělal, jak dlouho mu práce trvala, jaký materiál nebo zboží při práci spotřeboval. Pro jednoduchost si to můžeme představit jako klasický email, který obdržel pracovník společnosti. V zadání se dočetl, co má udělat a úkol vykoná. Pokud během procesu potřebuje součinnost jiného zaměstnance, tak mu daný email jednoduše přepošle. Z odpovědi se pracovník rozhodne, jak bude postupovat dál. Když je úkol splněn, tak do těla emailu zapíše, co k dokončení potřeboval, jak dlouho úkol plnil a email předá kompetentní osobě. Tento email potom může putovat k účetní (fakturace) nebo zadá úkol další osobě. Tak to proces pokračuje, dokud není vše hotovo. Po ukončení práce email obsahuje mnoho informací, od zadání a řešení, použité zboží a potřebné soubory (nabídky, rozpočty, smlouvy) po ekonomické přehledy, reakce zákazníka, historii, délku trvání atd. V analyzované společnosti toto všechno řeší modul zakázky. Každá zakázka má svého klienta, řešitele, zodpovědnou osobu, kategorie, komentáře, soubory, zboží atd. Každý zaměstnanec má naopak seznam zakázek, které jsou mu přiřazeny. Po přihlášení do systému tedy ihned ví, jaká práce na něho čeká. Kategorie zakázky vyjadřuje hlavní povahu činnosti, tedy například servis, nákup a prodej, administrativa a podobně. Slouží zejména pro filtrování zakázek stejného typu. Základní časová linie zakázky je tvořena komentáři jednotlivých pracovníků. Díky tomu lze snadno číst průběh zakázky, u každého komentáře je přesné datum a čas, autor a samotný text. Někdy se stává, že nová zakázka má vyšší prioritu než běžné zakázky. Aby bylo možné okamžitě vyfiltrovat tento druh zakázek, přibylo u zakázky pole priorita, které je možné vybrat ze dvou hodnot - normální a vysoká. Rozmýšlel jsem nad možností zavést například 5 úrovní priority, ale ukázalo se, že by tato možnost paradoxně zdržovala. Pokud je na výběr pouze ze dvou možností, je rozhodnutí okamžité - pracovník bez rozhodování zvolí vysokou prioritu. Pokud je na výběr z 5 možností, z 5 úrovní priorit, je pro pracovníka daleko těžší se rozhodnout pro správnou hodnotu. Musí posuzovat prioritu vzhledem k ostatním zakázkám,
3.2. ANALÝZA INFORMAČNÍHO SYSTÉMU SPOLEČNOSTI
11
Obrázek 3.2: Uživatelské rozhraní zakázky v systému
zdůvodnit si, proč je daná zakázka prioritnější než ostatní, nebo naopak méně důležitá. Takové rozhodování je zatěžující a nepřispívalo by k dobré použitelnosti aplikace. Detail každé jednotlivé zakázky je pak tvořen obdobně jako je email. V horní části je hlavička se jménem klienta, řešitelem, zodpovědnou osobou atd. Tělo zakázky většinou obsahuje hodně informací, proto je se informace pro přehlednost rozdělili do záložek, například: • komentáře • dokumenty • odpracované hodiny • seznam použitého zboží • historie Na zakázky lze nahlížet několika způsoby: • z pohledu řešitele - co má konkrétní osoba za úkoly • z pohledu klienta - jaká práce se aktuálně řeší pro konkrétního zákazníka • z pohledu kategorie - zobrazení všech servisních zakázek, obchodních zakázek atd.
12
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 3.3: Uživatelské rozhraní zakázky v systému - záložky
3.2.2
Dokumenty, tabulky, obrázky a ostatní soubory
Organizace firemních dokumentů, tabulek, obrázků a obecně souborů je velice problematická věc. Soubory se nejsnáze a také nejčastěji ukládají na tzv. file servery. Pro uživatele je to velice pohodlné, protože si adresářovou strukturu vytváří podobně jako v dokumentech na svém počítači. Jenže tato výhoda se časem přemění v obrovskou nevýhodu, protože logika názvů jednoho uživatele nemusí odpovídat logice druhého uživatele, verzování dokumentů prakticky neexistuje, ale diskový prostor se stále plní a plní a časem už nikdo neví, co je a co není aktuální. Odlišným úložištěm pro soubory je systém jako například Microsoft Sharepoint. Zde se dokumenty ukládají do databáze, kam lze snadno psát poznámky, verzovat, indexovat obsahy atd. Ale i toto na první pohled hezké řešení má velké trhliny např. právě v tom, že vše se ukládá do databáze (fyzicky na serveru do jednoho nebo více velkých souborů). Velikost takové databáze časem dosahuje jednotek nebo desítek GB (gigabyte), což je jednak problematické na zálohování, obnovování, ale také z hlediska licencování databázového serveru. V mém systému jsem se pokusil o kompromis a to v tom pohledu, že dokumenty sice ukládám do klasické adresářové struktury na file serveru, ale výchozí adresáře mi vytváří aplikace a ne samotní uživatelé. Taková adresářová struktura je jednak dostupná přes klasické sdílení složek, ale i z aplikace, tzn. přes webové rozhraní. Uživatel tím získává potřebné soubory (nabídky, kalkulace, smlouvy, grafické návrhy atd.), ale i popisné informace co je to za nabídku, proč tu je atd. ve formě komentáře v zakázce. Tím, že každou zakázku lze snadno nechat putovat mezi uživateli, docílím tím i jednoduchého koloběhu dokumentu (např. schvalování přijaté faktury).
3.2.3
Kontakty
Databáze kontaktů je pro společnost klíčová. Zákazníci, dodavatelé, výrobci, ti všichni mají mnoho kontaktních údajů, které je potřeba jednoduše ukládat. Při analýze specifikace kontaktů jsem zjistil, že tato samotná oblast by se mohla rozvíjet do značné hloubky.
3.2. ANALÝZA INFORMAČNÍHO SYSTÉMU SPOLEČNOSTI
13
Typů kontaktů je mnoho - jména, názvy společností, telefony, emaily, icq, skype, fax, webové stránky, adresy. Vyvstává tedy mnoho otázek. Kolik vlastně chceme ukládat těchto údajů? Chceme mít k dispozici neomezený počet emailů a telefonů nebo jejich počet omezíme? Jedna adresa nemusí vždy stačit, protože dodavatel může mít více poboček, každá pobočka má vlastní telefon a vlastní email. Každá další úroveň systém prohlubuje a snižuje dobrou použitelnost, protože pro pracovníka přináší nutnost mnoha akcí, aby provedl úkon, který chce. V rámci analýzy jsem dospěl k názoru, že nejlepší řešení bude použít jednu úroveň, ale v takové formě, aby byla variabilní a lehce ovladatelná. Počet ukládaných informací nebude omezen, takže ke každému typu kontaktní informace lze přiřadit neomezené množství dat a to včetně textového popisu.
3.2.4
Komunikace
V současné verzi informačního systému lze komunikovat mezi pracovníky pouze prostřednictvím komentářů v sekci zakázek. V situacích, kdy je potřeba upřesnění nebo dotaz v reálném čase, vyžaduje současné řešení určitý čas, než se daný pracovník do zakázky podívá a než odpoví. Jak jsem již zmiňoval, tato nevýhoda se obchází pomocí softwarových programů třetích stran, například Skype nebo ICQ. V rámci mé práce vytvořím v jádru aplikace možnost komunikace mezi pracovníky v reálném čase. Toto řešení má výhodu v tom, že komunikační data jsou uchována na serveru klienta a ne na serveru třetí strany, což zvyšuje bezpečnost obsahu a nezávislosti na dalších systémech. Pokud je pracovník v terénu, nemá sebou vždy všechny svoje komunikační programy. Díky tomu, že moje řešení bude integrované přímo v aplikaci, bude k dispozici kdykoli.
3.2.5
Upozornění a notifikace
Jak jsem se již zmínil v sekci Zakázky a úkoly, může mít určitý úkol větší prioritu než ostatní. Je tedy nutné udělat maximum pro to, aby se pracovníci věnovali této činnosti. K tomu slouží systém upozornění. Jakmile se v prioritní zakázce stane nová událost (úprava, přidání komentáře), upozornění vyžadá pozornost pracovníka. Formy notifikace: • email zaslaný na pracovní adresu pracovníka - tento způsob je nejúčinnější, pokud je ještě spárován mobilní telefon s danou emailovou adresou, potom může být reakce okamžitá • výstraha přímo v aplikaci - pokud je uživatel v systému přihlášen, může mu být upozornění na novou událost zobrazeno přímo
3.2.6
Historie akcí
Tato funkčnost je důležitá zejména pro vedení společnosti, které může lehce monitorovat výsledky práce, výsledky jednotlivých pracovníků. Stejně užitečná je informace pro pracovníky, kteří mohou zjistit, kdo na zakázce pracoval, kdo ji upravoval a kdy.
14
KAPITOLA 3. ANALÝZA A NÁVRH ŘEŠENÍ
Obrázek 3.4: Komunikační okna chatu
Kapitola 4
Realizace 4.1
Příprava
Prvním krokem při realizaci je výběr komponent a zvolení názvu projektu. Výběr komponent: • webový server • databázový server • skriptovací jazyk • pomocné knihovny
4.1.1
Webový server
Používám osvědčený a prověřený open-source webový server z dílny Apache [1]. Jeho znalost mi umožní rychlou instalaci a bezproblémové nastavení. Apache HTTP Server je robustní, komerčně využitelný projekt s otevřeným zdrojovým kódem. Je zřejmě nejpoužívanějším webovým serverem na světě a pro moji práci se výborně hodí. Jeho historie sahá až do roku 1995, dnes za tímto projektem stojí stovky dobrovolníků a mohu se spolehnout, že jeho vývoj bude i nadále pokračovat.
4.1.2
Databázový server
V dnešní době existuje řada databázových serverů, od plně profesionálního Oracle, přes Postgress, MS SQL, po volně šiřitelný MySQL server. Právě zmíněný MySQL je velmi populární relační databázový server, který má díky své popularitě miliony pracujících kopií. Od verze MySQL 5.0 nelze ani hovořit o primitivní databázi, protože obsahuje naprostou většinu moderních technologií. Můžeme zmínit například použití triggerů, pohledů, procedur, vložených poddotazů, podpora všech kódování. Je to tedy moderní nástroj, který je opět jednoduše použitelný, volně šiřitelný a přesto vynikající relační databázový server.
15
16
4.1.3
KAPITOLA 4. REALIZACE
Skriptovací jazyk
Moje znalosti se soustředí na platformu PHP, které je zpracováváno PHP modulem pro webový server Apache. Budu proto využívat PHP nejnovější verze. Jedná se o nejrozšířenější platformu webových serverů, umožnuje všechny operace, které moje práce bude zahrnovat.
4.1.4
Pomocné knihovny
Aby byla práce efektivní, je nutné využívat existující knihovny, které jednoduše a rychle umožňují vykonávat požadované funkce. Pro manipulaci se stránkou, efekty a podobně, budu používat javascriptový framework jQuery. Jeho konkrétní využití popíši dále v textu. Správný formát zápisu a podrobnou dokumentaci si lze prohlédnout na [6]
4.1.5
Název projektu - Opentis
Webovou aplikaci, kterou vyvíjím v rámci diplomové práce jsem pojmenoval Opentis. Toto jméno je vytvořeno ze slov Open-source Enterprise Information System. Opentis jsem zvolil, protože je to název krátký, dobře se vyslovuje i píše, při hledání na Internetu je to téměř unikátní slovo.
4.2
Adresářová hierarchie projektu
Zde popíši, jak to vypadá z hlediska adresářů, co kam patří a proč. /config /data /images /javascripts /languages /log /modul /php /styles
obsahuje obsahuje obsahuje obsahuje obsahuje obsahuje obsahuje obsahuje obsahuje
konfigurační soubory aplikace (údaje pro připojení do databáze atd.) dokumenty příslušné k jednotlivým zakázkám (podadresáře vytváří aplikace) obrázky používané v aplikaci vlastní i cizí javascriptové funkce a knihovny soubory s texty pro jednotlivé jazykové varianty soubory s logy jednotlivé moduly aplikace (adresář mohu konfigurací změnit) knihovny s PHP funkcemi definice CSS stylů aplikace
Tabulka 4.1: Adresářová hierarchie projektu V základním adresáři aplikace jsou umístěny PHP třídy, přihlašovací a hlavní stránka aplikace.
4.3
Použité frameworky
Prakticky jediným použitým frameworkem je jQuery. jQuery je javascriptový framework, který velmi výrazně usnadňuje práci s DOM elementy stránky, podporuje události, animace i technologii AJAX. Důvody, proč jsem si jQuery vybral:
4.4. JÁDRO APLIKACE
17
• je velice rychlý • knihovna má pouze několik málo kB (kilobyte) • má stručný zápis kódu • má perfektní dokumentaci • je vyvíjen a testován pro všechny známé internetové prohlížeče Je to elegantní a mocný nástroj, který webovou aplikaci může výrazně posunout kupředu. Existují také rozšíření, které jQuery dále vylepšují. Tyto rozšíření poskytují většinou konkrétní vlastnosti, které mohu jako programátor využít. Několik rozšíření jsem do mé webové aplikace také zařadil. Je to rozšíření idTabs, které umí pracovat se záložkami. Oficiální dokumentace je dostupná na [9]. Princip spočívá v tom, že je zobrazen vždy jeden určitý panel a ostatní jsou skryté. Pomocí akce (například kliknutí) na záložku může uživatel ihned změnit aktivní panel i se svým obsahem. Využívám ho při tvorbě menu i tam, kde je potřeba oddělit a zpřehlednit více informací na jedné stránce. Další použité rozšíření je ColorBox. Dokáže zobrazit daný obsah v novém panelu, který je zobrazen přes aktuální obsah okna. Původní okno je překryto poloprůhledným obrázkem a zaměří pozornost uživatele na nový obsah. Přidání frameworku do mé aplikace zařídí krátký úsek kódu v HTML stránce: <script type="text/javascript" src="javascripts/jquery-1.3.2.min.js"> Rozšíření idTabs a další potom snadno přilinkuji stejně jako hlavní knihovnu: <script type="text/javascript" src="javascripts/jquery.idTabs.min.js">
4.4
Jádro aplikace
Implementace aplikace začala vytvořením funkčního jádra, které poskytuje určitou základní funkčnost a poskytuje pracovní prostor modulům. Základní funkčnost jádra aplikace: • zobrazení přihlašovací obrazovky • odmítnutí nesprávných přihlašovacích údajů • akceptování správných přihlašovacích údajů a přihlášení do aplikace • řízení modulů • předání kontextu aplikace zvolenému modulu • odhlášení
18
KAPITOLA 4. REALIZACE
4.4.1
Vlastní PHP třídy
Dobře navržená aplikace co nejméně duplikuje kód, proto jsem si vytvořil některé základní třídy, které usnadňují práci a jednoduše se používají. Třída Page Pro základní stavbu stránky jsem vytvořil třídu Page, která metodou getHeader vytvoří hlavičku každé stránky. Obsahuje již přilinkované javascriptové knihovny a umožňuje díky dalším metodám: • setTitle() - nastavení nadpisu stránky • setKeywords() - nastavení klíčových slov stránky • setFileStyle() - nastavení, který soubor s kaskádovým stylem bude ke stránce přilinkován Zde je zdrojový kód souboru class_page.php, který obsahuje definici třídy Page. title = $mytitle; } function setKeywords($mykeywords){ $this->keywords = $mykeywords; } function setDescription($mydescription){ $this->description = $mydescription; } function setFileStyle($mystyle){ $this->file_style = $mystyle; }
’; return $str; } } ?> Tato třída se uplatní v každém skriptu, kde je potřeba vygenerovat klasickou stránku pro prohlížeč. Třída User Tato třída obsahuje proměnné a metody, které odrážejí vlastnosti a akce prováděné uživatelem systému. Nebudu uvádět všechny, ale zmíním nejdůležitější. Metoda loadData načítá vnitřní proměnné uživatele z databáze, podle zadaného parametru id_user, což je primární klíč tabulky user. V situaci, kdy jsou data již načtena z databáze, by jejich druhé načítání bylo zbytečné, zavedl jsem proto metodu loadFromArray, která má jako vstupní parametr pole. Další metody obsluhují vstup do aplikace a kontrolu platnosti údajů: • checkFirstLogin - vstupními parametry jsou uživatelské jméno a heslo. Funkce zkontroluje, zda daný uživatel existuje a pokud ano, zapíše informace do globálního pole SESSION
20
KAPITOLA 4. REALIZACE
• checkLoginSession - tuto funkci volám v každém skriptu, ve kterém potřebuji ověřit, zda je uživatel přihlášen. Pokud ano, je aktualizováno časové razítko poslední akce.
4.4.2
Vlastní obecné PHP funkce
V každém PHP skriptu, který zpracovává data z webových formulářů je nutné zajistit jejich načtení z globálních polí $_GET nebo $_POST. Pro automatizování práce jsem si napsal funkci get_variables. První parametr je pole jmen proměnných, které mají být načteny. Druhý parametr rozhoduje o tom, z jakého globálního pole budou vstupní data načítána (POST nebo GET). Třetí parametr je nepovinný a může obsahovat defaultní hodnotu pro případ, kdy proměnná ve vstupních datech neexistuje. function get_variables($arr, $type, $default = ’’){ foreach($arr as $item) { if($type == "POST"){ if(isset($_POST[$item])) $GLOBALS[$item] = $_POST[$item]; else $GLOBALS[$item] = $default; } if($type == "GET"){ if(isset($_GET[$item])) $GLOBALS[$item] = $_GET[$item]; else $GLOBALS[$item] = $default; } } } $ Pokud v aplikaci potřebuji načíst proměnnou action, která byla odeslána webovým formulářem metodou POST, použiji svoji funkci: get_variables(Array("action"), "POST");
4.4.3
Přihlášení do aplikace
Vstupní stránku tvoří přihlašovací formulář, který jsem se pokusil vytvořit interaktivně a zároveň bezpečně. Takto vypadá zdrojový kód přihlašovacího formuláře:
4.4. JÁDRO APLIKACE
21
Obrázek 4.1: Přihlašovací proces - start
Jakmile začne uživatel psát své přihlašovací jméno do prvního pole, je pomocí Javascriptové metody onkeyup volána funkce checkLoginName, která na pozadí odesílá pomocí technologie AJAX vepsaný text PHP skriptu. Tento skript ověří, zda dané uživatelské jméno skutečně existuje a pokud ano, vrátí tuto informaci přihlašovací stránce a pomocí Javascriptu je uživateli potvzeno správné zadání.
Obrázek 4.2: Přihlašovací proces - po potvrzení jména Aby byla zajištěna dostatečná bezpečnost, rozhodl jsem se, že zadávané heslo by nemělo v textové podobě vůbec opustit počítač uživatele. Docílil jsem toho tak, že ještě před odesláním formuláře webovému serveru se heslo transformuje pomocí kryptografické hašovací funkce MD5 1 . přímo v prohlížeči. Umožní to Javascriptová funkce. Tlačítko pro odeslání formuláře je do stránky vloženo až poté, co uživatel zadá heslo. Jakmile je formulář odeslán, jsou zadané údaje (uživatelské jméno a MD5 otisk hesla) odeslány PHP skriptu script-login-verify.php. Tento skript načte dané proměnné a pomocí speciální funkce mysql_real_escape_string() ošetří v případě nutnosti dané řetězce tak, abych je mohl bezpečně použít v SQL dotazu. Dále jsem musel myslet na případ, kdy má uživatel ve svém internetovém prohlížeči vypnutou podporu Javascriptu. Taková situace způsobí, že heslo se na straně uživatele nezmění na MD5 otisk. Kontrola přístupu by tak byla neúspěšná i v případě, že uživatel zadá správné heslo. Přihlašovací skript proto zkontroluje, zda délka přijatého hesla je 32 znaků. V opačném případě je provedena hašovací funkce až na straně serveru, standardní funkcí MD5 obsaženou 1 MD5 je zkratkou Message-Digest algorithm verze 5, je to kryptografický hašovací algoritmus, která ze vstupních dat vytvoří 128-bitový otisk. I velmi malou změnou ve vstupním řetězci získáme úplně jiný výsledný otisk. Algoritmus vymyslel Ron Rivest v roce 1995.
22
KAPITOLA 4. REALIZACE
Obrázek 4.3: Přihlašovací proces - po zadání hesla
v PHP. Jak jsem zmínil výše v textu, skript dále využije třídy User a postárá se o uložení potřebných informací do globální proměnné SESSION.
4.4.4
Implementace jádra aplikace
Jádro aplikace je reprezentováno hlavně souborem main.php, kterému je předáno řízení po úspěšném přihlášení uživatele. Uvedu nejdůležitější části, které jsou nezbytné pro chod aplikace. Pomocí direktivy session_start nejprve zapnu zpracování session. Potom pomocí funkce require_once vyžádám Loader. To je velmi důležitá část aplikace, která načítá všechny ostatní nastavení, knihovny, třídy a definice. Tento skript jsem vytvořil pro maximální úsporu zdrojového kódu. Následuje blok s využitím třídy User a její instance $user. Metoda checkLoginSession() se postará o to, aby se nepřihlášený uživatel nedostal do aplikace. Nepovolaná osoba je přesměrována funkcí locationLoginPage() na přihlašovací stránku. checkLoginSession() == FALSE) { $user->locationLoginPage(); } Skript pokračuje uložením informací do logovacího souboru. O to se postará třída Log a její metoda logThis(). Konstanta LOGFILECORE je definována ve skriptu Loader, který ještě vysvětlím dále. $log->logThis(LOGFILECORE, "main page"); Poté přichází na řadu směrování a rozhodování, jakému modulu se předá řízení.
4.4. JÁDRO APLIKACE
23
get_variables(Array("c"), "GET"); $arg = split("/", $c); $module_name = $arg[0]; include(MODULPATH.$module_name.’/control.php’); Skript Loader Tento skript automaticky načítá všechny použité nastavení, knihovny, třídy a definice. Pomocí mé vlastní funkce database_connect se také připojí k databází pomocí údajů v konfiguračním souboru. Pro tuto ukázku jsem vypustil ze zdrojového kódu některé komentáře. // include basic configuration include_once("config/base.php"); include_once("config/db.php"); // include language file include_once("languages/lang.".$web[’language’].".php"); // include functions and classes include_once("php/functions.php"); include_once("php/class_access.php"); include_once("php/class_page.php"); include_once("php/class_user.php"); // a dalsi [zkraceno] // connect to database database_connect($web[’db_host’], $web[’db_user’], $web[’db_pass’], $web[’db_name’]); // for developing error_reporting(E_ALL); // settings define("LOGSTATE", true); // paths define("MODULPATH", "./modul/"); define("LOGPATH", $_SERVER[’DOCUMENT_ROOT’]."/log/"); define("DATAPATH", $_SERVER[’DOCUMENT_ROOT’]."/data/"); define("DATAWEBPATH", "/data/"); // names define("LOGFILECORE", "core.log"); Při vývoji jsem měl problémy s definicí cesty pro datové soubory. Nakonec jsem musel vytvořit samostatné konstanty DATAPATH a DATAWEBPATH. Konstantu DATAPATH používám při práci se souborem na straně serveru, protože je doplněna o cestu z proměnné
24
KAPITOLA 4. REALIZACE
DOCUMENT_ROOT, konkrétně z globálního pole $_SERVER["DOCUMENT_ROOT"]. Pro potřeby uživatele je ovšem tato cesta nepoužitelná, a proto jsem zavedl konstantu DATAWEBPATH, která používá relativní zápis cesty. Díky tomu uživatel dostane adresu datového souboru ve formě, která je pro něj dostupná.
4.5
Uživatelské rozhraní
Skript na straně serveru musí vždy zaslat webovému prohlížeči korektní HTML stránku. Pro tento účel si vždy vytvořím instanci třídy Page a metodou getHeader jednoduše vytvořím hlavičku každé stránky. Výhodou je, že kód hlavičky je v každém místě stejný a úpravy se provádějí pouze na jednom místě. echo $page->getHeader(); Další podoba stránky je čistě na daném skriptu. Uživatelské rozhraní aplikace je vytvořeno pomocí div kontejnerů a kaskádových stylů. Konkrétně:
// hlavicka
// box aktivnich uzivatelu
// logo
// prikazova radka
// hlavni obsah
Pomocí jednoznačných identifikátorů (například: id="page") poté v souboru se styly (pro šablonu aplikace je to main.css v příslušném adresáři) uvedu definici vzhledu pro tento kontejner:
4.6. SYSTÉM MODULŮ
25
#page{ position: relative; width: 1200px; min-height: 400px; margin: 0 auto 0 auto; text-align: left; border: #C0C0C0 1px solid; } Tento zápis znamená, že pozice bloku je určena relativně k ostatním, šířka bloku je 1200px, minimální výška 400px, blok je vystředěn v okně prohlížeče, text začíná vlevo a blok je obalen okrajem v RGB barvě C0C0C0. Podobně pro další bloky jsem určil jejich vzhled. Při tvorbě rozhraní jsem se snažil dodržovat zásady přístupného a použitelného webu podle [13] Takto vypadá kompletní uživatelské rozhraní aplikace:
Obrázek 4.4: Uživatelské rozhraní aplikace
4.6
Systém modulů
Modularita aplikace je jedním ze základních úkolů, které jsem při realizaci musel vyřešit. Řešení musí být dostatečně robustní, ale zároveň ne příliš složité. Moduly jsou umístěny v samostatném adresáři, jak jsem uvedl výše. Řízení v aplikaci určuje parametr c, který je předáván v URL adrese. Jádro (v pojetí MVC architektury je to řadič) tento parametr načte a dále zpracuje. Obsah parametru c je
Obrázek 4.5: URL adresa a řízení aplikace rozdělen podle řídícího znaku, kterým je lomítko. Řetězec před lomítkem tak určuje modul a řetězec za lomítkem potom identifikátor stránky v daném modulu. V tomto případě tedy řadič rozpozná, že žádáme modul projects a zobrazení stránky all. Do řetězce za lomítkem
26
KAPITOLA 4. REALIZACE
neumisťuji celý název souboru v modulu. Předávám v tomto místě pouze identifikátor, modul rozhodne sám jakou stránku zobrazí. To jsem zařídil následujícím způsobem: • řadič zjistí, jaký modul je žádán • využiji znalost názvu modulu a vyžádám soubor control.php, který se nachází v daném modulu (konkrétně tedy v ukázkovém příkladě /modul/projects/control.php) • v tomto podřadiči si modul určí, jakou podstránku zobrazí Řadič v modulu je realizován klasickým příkazem switch, který v jednotlivých větvích definuje názvy souborů podstránek. Takto vypadá zdrojový kód:
4.7
Lokalizace aplikace
Zpočátku se mi zdál problém lokalizace aplikace vcelku malicherný. Co může být složité na tom, ukládat textové řetězce mimo zdrojový kód? Realita ale ukázala, že tento úkol není zdaleka tak triviální. Nejde totiž pouze o překlady textů, ale i tzv. internacionalizaci. Tím je myšlena schopnost aplikace pracovat s daty podle pravidel dané země a jazyka. Teprve druhý krok je lokalizace samotná, čili překlad uživatelského rozhraní aplikace. Nejprve jsem přemýšlel o možnosti ukládání těchto textů do databáze. Při promýšlení jsem ale zjistil, že správa takové lokalizace nebude nejjednodušší. Přidání další jazykové mutace nutně znamená změnu struktury tabulek. Navíc získávání textů způsobuje zátěž pro databázový stroj. Uvažoval jsem tedy nad dalšími možnostmi.
4.7. LOKALIZACE APLIKACE
27
Dále mě napadlo udržovat textové řetězce v externím souboru typu INI. Ve světě operačního systému Windows je považován za běžný formát konfiguračních souborů. Ale projekt vedu jako multiplatformní a nezávislý, tento způsob jsem tedy také nevybral. Navíc by bylo nutné vyřešit parsování textů dle platného formátu těchto souborů. Nejlepší řešení pro můj projekt je zřejmě asociativní pole. Pomocí klíčů budu definovat jednotlivé texty, které budou uvedeny v externím souboru. Každá jazyková mutace tak bude v jednom samostatném souboru. Pro přístup k logalizovaným textům jsem navrhnul funkci, které se pouze předá klíč požadovaného textu. Je možné, že v budoucnu se potřeby projektu změní, proto nebudou texty získávány z pole přímo. Pokud se změní způsob uložení textů, nebude nutné zasahovat do zdrojových kódů, ale pouze se změní daná funkce. Při studiu této problematiky jsem narazil na pokročilý systém GNU GetText, což je knihovna pro práci s texty a jejich lokalizací. Je dostupná i pro PHP, ale rozhodl jsem se ji zatím nevyužít, protože při vývoji této aplikace narážím na řadu problémů a úspěšné řešení všech vyžaduje mnoho času. Abych dokončil aplikaci včas, zvolil jsem vlastní řešení, které je možné v budoucnu kdykoli zaměnit za profesionální řešení typu knihovny GetText. Správa lokalizací Soubory s lokalizacemi budu udržovat na centrálním místě, aby byla zajištěna aktualizace verzí. Další provozovatelé systému tak budou mít vždy přehled o aktuálnosti verze. Jak konkrétně jsem tedy problém realizoval? Pro soubory s lokalizovanými texty jsem vyhradil adresář: /languages/ V tomto adresáři jsou umístěny soubory jazykových mutací a to s názvem souborů ve tvaru: • lang.cz.php - pro českou jazykovou mutaci • lang.en.php - pro anglickou jazykovou mutaci • atd. Vnitřní strukturu těchto souborů jsem navrhl takto: $apptext[’Logged in’] = ’Přihlášen’; $apptext[’Logout’] = ’Odhlásit se’; Je to tedy definice jednotlivých textů v asosiativním poli, kde jako klíč prvku pole se používá anglický ekvivalent. Nastavení jazyka pro celou aplikaci jsem umístil do základní konfigurace, která se nachází v cestě: /config/base.php V tomto souboru jsem jednu z direktiv pojmenoval language a její obsah odpovídá nastavenému jazykovému souboru, respektive jeho dvoupísmenné zkratce. $web[’language’] = ’cz’;
28
KAPITOLA 4. REALIZACE
A jak vypadá použití? Přímo ve zdrojovém kódu potom místo klasického zápisu echo ’Přihlášen :’; použiji moji funkci, která vrátí správný překlad vzhledem k nastavení aplikace myGetText("Logged in").’ :’; Samotná funkce myGetText potom převezme jako parametr klíč, který je současně alternativním textem. Tento text se použije místo překladu, pokud toto spojení není obsažené v nahraném lokalizačním souboru. function myGetText($key){ global $apptext; if(isset($apptext[$key])) return $apptext[$key]; else return $key; }
4.8
Použití API
V zadání mé diplomové práce je i použití API existujících služeb. Pro potřeby mého projektu jsem využil rozhraní služby Google Maps.
4.8.1
Google Maps
Google Maps API dovoluje dle [5] vložit na webovou stránku vlastní mapové podklady pomocí Javascriptu. Jaké funkce podporuje? • zobrazení mapy • nastavení tlačítek mapy (přibližování, změnu klasické mapy na satelitní pohled atd.) • přidávání vlastních bodů zájmu • vytváření tras mezi definovanými body nebo adresami V mé aplikaci se pracuje s kontakty uživatelů nebo zákazníků, můžeme proto využít Google Maps API pro zobrazení jejich polohy přímo v aplikaci. Podmínkou použití Google Maps API je vygenerování vlastního API klíče. Je to 86 bytový řetězec, který je unikátní pro jednotlivé domény. Jeho získání je velmi jednoduché, stačí na příslušné webové stránce vyplnit žádost a obratem se zobrazí unikátní API klíč pro vaši aplikaci. Dokumentace Google Maps API je velice podrobná a s jeho správným použitím jsem měl pouze malé problémy. Ty se týkaly zejména směrování a zobrazení trasy. Pro moji aplikaci využívám vloženou mapu v modulu kontaktů a zobrazuji trasu z výchozí adresy do adresy zákazníka. Takto jsem navrhnul rozhraní práce s mapou:
4.9. CENTRÁLNÍ VYHLEDÁVÁNÍ
29
Obrázek 4.6: Interaktivní mapa - využití Google Maps API
4.9
Centrální vyhledávání
Otázka vyhledávání dat v aplikaci není triviální úkol. Modularita aplikace ztěžuje v tomto případě situaci, protože jádro aplikace nemůže do budoucna vědět, jaké další moduly budou v aplikaci přítomné. Snažil jsem se proto přijít na řešení, které by drželo krok s aktuálním stavem aplikace. Podle mého názoru ideálním řešením je nechat hledání na jednotlivých modulech. Musel jsem proto vyřešit, jakým způsobem rozhodnout, který modul bude o výsledcích hledání rozhodovat. Vymyslel jsem proto centrální vyhledávací prvek, což je vstupní pole, které je viditelné na každé stránce aplikace. Umístil jsem ho do hlavičky nad menu:
Obrázek 4.7: Centrální vyhledávací prvek je umístěn v hlavičce vedle loga Vstupem je tedy klasický webový formulář, který odesílá vepsaný text skriptu s názvem script-search.php:
30
KAPITOLA 4. REALIZACE
Hledání samotné jsem realizoval jako kombinaci klíčového slova a hledaného výrazu. Pokud uživatel hledá projekt a pamatuje si část projektového čísla, napíše do vyhledávání "projekt 004". Skript script-search.php s pomocí databáze zjistí, že klíčové slovo "projekt" patří k modulu projects. Další zpracování hledání převezme tento modul. Zařídím to pomocí funkce Header(), která přesměruje požadavek na podstránku příslušného modulu a připojí hledaný výraz (v tomto případě "004"). Header("Location: /main.php?c=$module_name/search&search_text=$search_value"); Podstránka hledání zpracuje požadavek a zobrazí výsledky hledání. Konfigurace přiřazení klíčových slov k jednotlivým modulům se nachází v nastavení aplikace, což je mimochodem také samostatný modul settings. Textové pole centrálního vyhledávání jsem navíc opatřil systémem automatického dokončování pomocí jQuery pluginu Autocomplete. Podle aktuálního textu jsou uživateli nabídnuty nejčastěji používané volby. Více o tomto pluginu se lze dozvědět v [7].
4.10
Box aktivních uživatelů
Při vývoji aplikace jsem si uvědomil, že bych jako uživatel aplikace chtěl vidět, kdo z mých spolupracovníků je právě v systému přihlášen. Mohl bych s daným uživatelem začít pracovní rozhovor pomocí vnitřního komunikačního systému nebo mu přidělit prioritní projekt. V první verzi této funkčnosti jsem do bočního plovoucího okna vypisoval jména aktuálně přihlášených uživatelů. Toto řešení bylo prostorově náročné a nesplňovalo podmínky interaktivity. Pokud zobrazená stránka zůstala na monitoru třeba 30minut, byl zobrazený stav již neaktuální a nereflektoval realitu. V druhé verzi jsem myslel na úsporu místa a místo jmen jednotlivých uživatelů jsem do horního menu aplikace umístil červené nebo zelené kruhové symboly. Ty prezentovaly jednotlivé uživatele a jejich aktuální stav. Problém byl s rozlišením uživatelů, zavedl jsem tedy vedle symbolů iniciály každého uživatele. Ovšem při testování se ukázalo, že uživatelé nejsou s tímto zobrazením spokojeni, přehlednost není dobrá. Více tento problém popíši v sekci Testování. Ve třetí verzi jsem vyřadil grafické symboly a nechal místo nich pouze čtverečky s podbarvením pomocí kaskádových stylů. Do vnitřku boxu se pohodlně vejdou iniciály uživatele a přehlednost je velice dobrá. Navíc jsem pro tento box vymyslel další funkčnost, která více spojuje celou aplikaci. Iniciály uživatele jsou tvořeny odkazem, pod kterým se skrývá nabídka souvisejících akcí. Po kliknutí na iniciály uživatele se zobrazí okno s nabídkou akcí. Uživatel tak může ihned
zahájit komunikaci se spolupracovníkem, přidělit mu projekt nebo se podívat na kontakty, ve kterých je uveden daný pracovník jako zodpovědná osoba. Panel uživatelů je navíc za pomoci technologie AJAX obnovován každých 10 vteřin, aby byla zajištěna aktuálnost dat. Javascriptová funkce usersActivity využívá framework jQuery a na pozadí aplikace se dotazuje skriptu ajax-users.php Konkrétní zápis AJAXového volání uvádím zde: function usersActivity(){ $.get("ajax-users.php", function(data){ users_value = data; $("#users").html(users_value); } ); setTimeout("usersActivity()", 10000); } První parametr metody GET je skript, na který požadavek směřuje. Druhý parametr je definice funkce, která je oznáčována jako callback. Této funkci je předána obsluha po dokončení vzdáleného volání. Vnitřní proměnná data potom obsahuje to, co PHP skript vypsal na svůj výstup. Selektor #users se následně postará o správné umístění získaného obsahu do příslušného kontejneru div. Více se o práci s AJAXem můžete dozvědět v [12] a v [11].
32
KAPITOLA 4. REALIZACE
Obsazení jednotlivých buněk lze nastavit v modulu settings. Volné buňky obsahují odkaz na vloženou stránku, kde lze zvolit z uživatelů, kteří ještě nejsou umístěni v panelu. Pro tento obrázek jsem jména skutečných uživatelů zakryl.
Obrázek 4.10: Panel uživatelů a jeho nastavení
Využívám při tom plugin Colorbox, který definují následujícím způsobem: <script type="text/javascript"> $(document).ready(function(){ $(".iframe").colorbox( {width:"500px", height:"400px", iframe:true, overlayClose: false, opacity: 0.7 } ); }); Nové okno bude mít šířku 500 pixelů, výšku 400 pixelů a pozadí bude ze 70% neprůhledné. Aktivace okna probíhá klasickým odkazem, který má parametr class nastaven na hodnotu "iframe". Kompletní dokumentaci tohoto užitečného pluginu jsem se získal na stránce [8].
4.11
Menu aplikace
V úplně první verzi jsem vytvořil menu aplikace vertikální. Po najetí kurzorem myši na danou nabídku se vysunul panel s podnabídkou. Díky testování jsem nakonec tohoto způsobu řešení menu zanechal a připravil nový způsob. Je to menu horizontální vytvořené za pomoci jQuery pluginu idTabs. Tento plugin umí v reálném čase přepínat obsah definovaných bloků. Základní menu je vygenerováno s odkazem na jednotlivé podmenu a plugin idTabs se postará sám o jejich okamžité zobrazení. Celé menu je tedy načteno ihned, ale zobrazena je pouze
4.12. STANDARDNÍ MODULY
33
příslušná část. Položky a podpoložky menu jsou uloženy v databázové tabulce a za jejich správné vygenerování zodpovídá jádro aplikace.
Obrázek 4.11: Horizontální menu webové aplikace Opentis
4.12
Standardní moduly
Moje webová aplikace obsahuje několik základních modulů, které jsou pro správný běh aplikace nutné. Další moduly mohou být samozřejmě doplněny. V dalších sekcích popíši standardní moduly, které jsou v současné době v aplikaci implementovány.
4.12.1
Modul evidence uživatelů
Tento modul pokrývá evidenci uživatelů, jejich přidávání, editaci údajů, vyhledávání a další. Informace o uživatelích jsou uloženy v databázové tabulce users. V adresáři modulů je uložen pod názvem evidence. Systém správy kontaktních údajů uživatelů pracuje na stejném principu jako v modulu kontaktů a popíši ho dále. Modul evidence uživatelů je reprezentován zejména soubory page-users.php a page-user-edit.php. První jmenovaný vypisuje uživatele systému do přehledné tabulky, kterou je možné dynamicky řadit, jak uživatel požaduje. Řazení se aktivuje kliknutím na nadpis sloupce. Tuto funkci poskytuje Javascriptový plugin TableSort, více se o něm lze dozvědět na stránce [4].
4.12.2
Modul kontaktů
Informační systém společnosti potřebuje svoji databázi kontaktů. Modul s názvem contacts pokrývá správu kontaktů společnosti, jejich zakládání, editaci, vyhledávání. Základní informace o kontaktech jsou uloženy v databázové tabulce customers. Na uložení neomezeného počtu kontaktních údajů jsem realizoval obecný systém. Nejprve uvedu ER Model vytvořený v ER Modeláři: Tabulka contact_types obsahuje typy kontaktů, což může být například emailová adresa, telefon, fax, webová stránka, bankovní účet, Skype, ICQ nebo klasická poštovní adresa. Tabulka contact_owners definuje možné vlastníky daného kontaktního údaje, například uživatel (user) nebo zákazník (customer). Tabulka contacts potom dává uložené informaci jednoznačného vlastníka (určeného pomocí sloupců id_item a id_contact_owner), dále jednoznačný typ (id_contact_type). Klasická poštovní adresa má více rozličných údajů, proto jsem se rozhodl ukládat adresy zvlášť do tabulky contact_address. Jako spojovací prvek je v takovém případě použita hodnota value, která obsahuje primární klíč tabulky s adresami (proto je v obrázku entita contact_address oddělena od zbytku modelu)
34
KAPITOLA 4. REALIZACE
Obrázek 4.12: ER model systému ukládání kontakních údajů
4.12.3
Modul zakázek
Modul zakázek je uložen v adresáři modulů pod názvem projects. Informace o zakázkách jsou uloženy v databázové tabulce se stejným názvem projects. Každá zakázka má své číslo, které je vytvářeno automaticky ve formátu YYMM-NNNN, kde: • YY je dvojčíslí označující rok (např. 10) • MM je dvojčíslí označující měsíc (např. 01) • NNNN je čtyřčíslí, které vyjadřuje číslo zakázky v pořadí, tedy každá nová zakázka má číslo o 1 vyšší Poslední použité číslo zakázky se ukládá v tabulce projects_settings Zakázka má dále svůj název, identifikátor zákazníka, řešitele (uživatel systému, který danou zakázku aktuálně řeší), datum vytvoření, aktuální stav, den dokončení a prioritu. Možné stavy zakázky jsou uloženy v databázové tabulce projects_states a možné kategorie v tabulce projects_categories. K zakázce je možné psát komentáře, ty jsou ukládány do tabulky projects_comments. Pro lepší přehled jsem opět vytvořil ER model vztahů mezi entitami. Jak vypadá prostředí detailu zakázky spolu s komentáři se můžete podívat na obrázku 4.14. Velkou přidanou hodnotou je spojení zakázek a dokumentů. Každá zakázka má v datové oblasti svůj adresář, kam je možné nahrávat dokumenty. Uživatelé mají tento adresář jako sdílený diskový prostor, takže mohou jednoduše z prostředí operačního systému ukládat
4.12. STANDARDNÍ MODULY
35
Obrázek 4.13: ER model vztahů zakázek a komentářů
vytvořené dokumenty přímo k dané zakázce. V záložce "Dokumenty" jsou tyto soubory ihned viditelné a lze je zmínit v textu nového komentáře. Pro jednoduchost ovládání jsem vytvořil u každého souboru textové pole, které stačí zkopírovat do komentáře a systém automaticky vytvoří odkaz na daný soubor. Tato funkce přináší zrychlení a zefektivnění práce. Pro uživatele, kteří nejsou aktuálně připojeni k podnikové síti, jsem vytvořil formulář, pomocí kterého lze snadno nahrát svoje soubory k příslušné zakázce. Přehled dokumentů zakázky a formulář pro nahrávání je vyobrazen na obrázku 4.15.
36
KAPITOLA 4. REALIZACE
Obrázek 4.14: Detail uživatelského rozhraní modulu zakázek
4.12. STANDARDNÍ MODULY
Obrázek 4.15: Detail uživatelského rozhraní dokumentů zakázky
37
38
KAPITOLA 4. REALIZACE
Kapitola 5
Testování V průběhu vývoje jsem jednotlivé prototypy testoval na vzorku uživatelů. Zde popíši několik takových testů.
5.1
Testování uživatelského rozhraní
První testování proběhlo již v počátku vývoje a týkalo se uživatelského rozhraní a jeho parametrů. Konkrétně se jednalo spíše o anketu používaného rozlišení na pracovních stanicích a noteboocích. Aplikaci jsem navrhnul jako okno s fixní šířkou a zajímalo mne, jakou maximální hodnotu je dobré použít vzhledem k potřebám uživatelů. rozlišení 1680x1050 1280x1024 1920x1200 1280x800 1400x1050
četnost 12 9 7 4 3
Tabulka 5.1: Četnost používaných rozlišení uživatelů Z uvedených dat je vidět jasný trend v používání širokoúhlých monitorů. Z ankety jsem usoudil, že fixní šírku okna aplikace nastavím na hodnotu 1200 pixelů. Rezervu 80 pixelů ponechám na vizuální oddělení aplikace.
5.2
Testování panelu aktivních uživatelů
Box aktivních uživatelů aplikace prošel při vývoji několika změnami. První verzi jsem vytvořil pouze jako seznam aktuálně přihlášených uživatelů. Bylo zřejmé, že toto není dobré řešení a uživatelé navrhovali další požadavky. Každá z 5 testovaných osob uvedla, že toto řešení je prostorově náročné a zabírá na obrazovce mnoho místa. Další 3 lidé potom uvedli, že tento jednorázový výpis není pro ně ani užitečný, protože není aktuální.
39
40
KAPITOLA 5. TESTOVÁNÍ
Pokud zůstane stránka zobrazena dalších 20 minut, stav na obrazovce už nemusí odpovídat realitě. Tyto poznámky jsem zanalyzoval a vytvořil druhou verzi. Pro úsporu místa jsem místo jmen uživatelů použil grafické symboly. To mi dovolilo udělat malý box se všemi uživateli. Červený symbol pro neaktivního uživatele a zelený pro aktivního. Pro rozlišení o jakého uživatele se jedná, jsem vedle daného symbolu uvedl iniciály uživatele. Tento box navíc již nebyl statický, ale za pomoci technologie AJAX je každých 10 vteřin zobrazen znovu a reflektuje tak realitu situace. Při testování byli uživatelé s aktuálností spokojeni, ale ukázalo se, že přehlednost zobrazení není dobrá. Já jako autor jsem měl o umístění grafickým symbolů jasno, ale někteří uživatelé byli zmateni. Tabulka totiž neměla viditelné okraje, a tak nebylo možné na první pohled určit, jestli symbol patří uživateli před nebo za iniciály. Řešení jsem tedy přepracoval ještě jednou a grafické symboly jsem vypustil. Místo toho jsou políčka tabulky ohraničeny a iniciály jsou uvedeny uvnitř. Stav uživatele je zobrazen pomocí barvy pozadí dané buňky tabulky. Toto řešení se při testování ukázalo jako nejlepší a dostatečné přehledné. Z připomínek jednoho z uživatelů jsem doplnil i velmi užitečnou funkci lokálního menu. Iniciály uvnitř buňky tabulky slouží zároveň jako odkaz, po jehož aktivování se zobrazí lokální menu pro daného uživatele.
Obrázek 5.1: Panel uživatelů slouží i jako lokální menu daného uživatele
5.3
Testování menu aplikace
V první verzi aplikace bylo menu vytvořeno vertikální, podpoložky se zobrazovaly ve vysouvacím panelu a další větvení bylo vytvořeno stejným způsobem. Při testování s uživateli se ukázalo, že tento způsob tvorby menu není ideální, protože dosažení zanořené položky vyžaduje přesný pohyb kurzoru a zvýšenou pozornost. V případě, kdy uživatel vyjel kurzorem myši mimo vysouvací nabídku se tato ztratila a uživatel musel začít znovu. Takové chování nepřispívá k dobré použitelnosti aplikace. Využil jsem proto plugin idTabs. S jeho pomocí jsem vytvořil menu horizontální a které má pouze 2 úrovně. Prvním kliknutím se zobrazí podnabídka a druhým kliknutím uživatel zvolí požadovanou stránku. Jakýkoli pohyb kurzoru myši neovlivní aktuální stav menu. Položky jsou dostatečně velké a riziko chybné volby se tím snižuje.
5.4. OBECNÉ TESTOVÁNÍ
41
Obrázek 5.2: Horizontální menu webové aplikace Opentis
5.4
Obecné testování
Každou dokončenou část aplikace jsem testoval tak, že jsem zkoušel: • aktivovat všechny existující odkazy - aplikace vždy musí zobrazit korektní stránku • do formulářových polí jsem vkládal standardní i speciální znaky - aplikace je musí umět ošetřit a dokončit operaci Aplikaci jako celek jsem také testoval v existujících webových prohlížečích. Přesto, že by všechny prohlížeče měly zobrazovat webové stránky shodně, v praxi tomu tak není. Testováním jsem zjistil, že funkce aplikace fungují shodně ve všech webových prohlížečích. Rozdíly ve vykreslování obsahových kontejnerů, zejména u prohlížeče Internet Explorer, lze vyřešit speciálním kaskádových stylem, který s rozdíly počítá a upraví je.
42
KAPITOLA 5. TESTOVÁNÍ
Kapitola 6
Srovnání s existujícími řešeními Při rešerši existujících řešení jsem nalezl několik konkurentů. Zmíním jejich vlastnosti a výhody či nevýhody.
6.1
Feng Office
Feng Office nabízí online řešení pro společnosti podobně jako moje aplikace. Umožňuje správu úkolů, kontaktů, poznámek, událostí a podobně. Je to systém založený na webových stránkách a dá se označit za SaaS, neboli Software as a Service, software jako služba.
Obrázek 6.1: Ukázka rozhraní aplikace Feng Office - zdroj: http://www.fengoffice.com Toto integrované řešení pro spolupráci lidí ve společnosti nabízí 2 typy služby: • Feng Sky - instalace Feng Office na serverech této společnosti, doporučují pro začínající společnosti • Feng Onsite - Feng Office na vlastním serveru, doporučují pro větší společnosti 43
44
KAPITOLA 6. SROVNÁNÍ S EXISTUJÍCÍMI ŘEŠENÍMI
Výhodou aplikace je značná propracovanost, která z mého pohledu hraničí až s nepřehledností. Při testování tohoto produktu jsem narazil na určité chyby v logice, ale je možné, že je to dáno délkou používání a chybějící dlouhodobou zkušeností. Hlavní nevýhodu této služby vidím ve zpoplatnění. Měsíční poplatky jsou odvozeny od počtu uživatelů a s ním je omezena i použitelná disková kapacita. To může být velice omezující a pro začínající společnost je každý paušální poplatek zátěží. Toto řešení je dodáváno jako hotová služba a možnosti přizpůsobení budou v tomto případě, myslím, značně omezené. Zde je tabulka s měsíčními poplatky a pravidly: počet uživatelů 1 5 10 20 40
disková kapacita 300MB 1GB 3GB 10GB 20GB
měsíční poplatek 10$ 25$ 68$ 179$ 299$
Tabulka 6.1: Měsíční poplatky služby Feng Office Webová stránka této aplikace má adresu: http://www.fengoffice.com
6.2
Zoho
Zoho nabízí velice rozsáhlý soubor aplikací a služeb pro práci online na Internetu. Aplikace jsou pro jednotlivce zdarma, ale pro společnosti jsou opět zpoplatněny. Zoho je divize společnosti ZOHO Corporation, která také vyvíjí software. Popis všech součástí z nabízených balíků by zabral mnoho stran, proto alespoň uvedu některé zástupce: • Zoho Mail - webová aplikace pro přístup k emailovým schránkám • Zoho Writer - aplikace pro tvorbu a úpravu dokumentů typu Microsoft Word • Zoho Sheet - aplikace pro tvorbu a úpravu tabulek typu Microsoft Excel • Zoho Show - aplikace pro tvorbu a úpravu prezentací typu Microsoft PowerPoint • Zoho Projects - správa úkolů, projektů a plánování • Zoho Planner - aplikace pro osobní poznámky, seznamy osobních úkolů, upozorňování a prostor pro poznámky • Zoho Chat - aplikace pro podporu komunikace v reálném čase, propojitelná s existujícími protokoly komunikačních sítí • Zoho Meeting - aplikace pro tvorbu schůzek, konferencí a sdílení dokumentů • a další
6.3. GOOGLE APPS
45
Obrázek 6.2: Nabídka součástí z balíku Zoho služeb - zdroj: http://www.zoho.com
Ukázka webových stránek s nabídkou jednotlivých součástí: Výhodou řešení Zoho je široká nabídka služeb s možností nastavení a provázáním jednotlivých aplikací. Nevýhodou je zpoplatnění každé komponenty zvlášť. Cenová politika společnosti Zoho je poměrně složitá, a proto zde neuvedu výčet. Celkový přehled cen je dostupný na adrese: http://www.zoho.com/pricing.html Poplatky jsou opět svázány s určitými parametry dané komponenty, například počtem uživatelů, počtem založených projektů, dostupnou diskovou kapacitou atd. Pro středně velkou společnost se tak součet poplatků může vyšplhat daleko výše, než se na první pohled zdá. Webová stránka balíku aplikací má adresu: http://www.zoho.com/
6.3
Google Apps
Společnost Google, stojící za nejznámějším a nejpoužívanějším vyhledávačem, vytvořila v průběhu let mnoho dalších aplikací. Například balík webových kancelářských aplikací Google Docs, dále Google Mail (známý spíše jako Gmail), kalendář Google Calendar, komunikátor Google Talk a další. Ukázka webových stránek s nabídkou jednotlivých součástí: Souhrnně je nabízen balík hostovaných aplikací pod názvem Google Apps. Co tento balík konkrétně nabízí? • Gmail pro firmy - 25GB úložiště, garantovaná dostupnost služby 99,9 • Google Calendar - pro správu a plánování událostí, jejich sdílení a synchronizace • Google Docs - balík kancelářských aplikací pro tvorbu dokumentů, tabulek a prezentací • Google Groups - dovoluje uživateli vytvořit diskuzní skupiny, podporuje sdílení, vyhledávání
46
KAPITOLA 6. SROVNÁNÍ S EXISTUJÍCÍMI ŘEŠENÍMI
Obrázek 6.3: Logo spojených http://www.google.com/apps/
aplikací
balíku
Google
Apps
-
zdroj:
• Google Sites - aplikace pro návrh jednoduchých webových stránek bez nutnosti programování Služba pro komerční společnosti má název Google Apps Premier Edition nabízí toto řešení za 50 dolarů za uživatele na 1 rok. Garantovaná dostupnost služeb je 99,9%. Podporována je i součinnost se systémy Blackberry a Microsoft Outlook. Toto řešení je vhodné zejména pro menší společnosti, které nepotřebují robustní správu projektů nebo úkolů. Google Apps skvěle zpracovává emaily, dokumenty, podporuje jejich revize (tedy změny obsahu v čase), sdílení, štítkování. Limity má v počtech zpracovávaných souborů, jejich velikosti. Rizika společná pro všechny aplikace jsou ztráta konektivity, ztráta dat nebo nedostupnost služby.
6.4
Zhodnocení vlastního přínosu práce
Přínos mé aplikace Opentis vidím v těchto bodech: • je to moderní webová aplikace, která umožňuje spolupráci lidí kdekoli a kdykoli pouze za použití Internetu • integrované řešení pro správu úkolů, zakázek, kontaktů, dokumentů a dalších bez omezení • je zcela zdarma
6.4. ZHODNOCENÍ VLASTNÍHO PŘÍNOSU PRÁCE
47
• modularita aplikace umožňuje rozšiřování a vývoj nových modulů • jednoduchost a přehlednost podporuje produktivitu práce • klient si může aplikaci nainstalovat na vlastní server a tím snížit závislost na produktech třetích stran a odstranit riziko nedostupnosti aplikace z důvodu výpadku Internetu
48
KAPITOLA 6. SROVNÁNÍ S EXISTUJÍCÍMI ŘEŠENÍMI
Kapitola 7
Závěr a zhodnocení splnění cílů 7.1
Závěr
Cíle diplomové práce byly splněny, aplikace byla analyzována, navržena a implementována v souladu s požadavky práce i požadavky moderní aplikace. Aplikaci vyvíjím jako volný software, tedy s myšlenkou open-source, otevřeného zdrojového kódu. Aplikace je nyní volně přístupná na síti Internet. Společnost ÚVT, s.r.o. testuje předfinální verzi aplikace a jakmile bude systém odladěn, bude nasazen jako hlavní informační systém společnosti. Aplikace je variabilní, modulární a díky možnosti nastavení najde využití v mnoha typech zadání.
7.2
Zhodnocení splnění cílů práce
Úkolem této diplomové práce bylo navrhnout a implementovat webovou aplikaci, která bude moci nahradit stávající nevyhovující systém společnosti ÚVT, ale bude také moci být použita obecně pro začínající firmy, skupiny, sdružení. • základní úkol byl kompletně splněn a webová aplikace včetně zdrojových kódů je nyní v první verzi přístupná na webových stránkách http://opentis.com • aplikace byla dle zadání navržena modulárně a poskytuje jádro se základními funkcemi • aplikace díky standardním modulům umožňuje evidenci uživatelů, kontaktů, dokumentů, zakázek a komentářů • v aplikaci je zařazen modul, který velice jednoduše zobrazí aktuálně pracující uživatele a umožňuje jejich okamžitou komunikaci pomocí chatu v reálném čase • v aplikaci bylo využito API stávajících služeb, například díky Google Maps API je adresa kontaktu (například zakazníka) a trasa k této adrese ihned zobrazena na mapě přímo v aplikaci • aplikace obsahuje pole pro centralizované hledání a výsledky zpracovává vždy příslušný modul díky systému klíčových slov
49
50
KAPITOLA 7. ZÁVĚR A ZHODNOCENÍ SPLNĚNÍ CÍLŮ
• kód aplikace byl psán objektově a byl při vývoji řádně komentován a dokumentován • aplikace a její prototypové části byly testovány na vzorcích uživatelů a připomínky byly implementovány v další iteraci • aplikace je založena na produktech s otevřeným zdrojovým kódem a její nasazení je velice snadné
7.3
Další možnosti pokračování práce
Protože jsem se rozhodl vyvíjet tuto webovou aplikaci otevřeně, bude i vývoj nadále pokračovat a je možné, že se přidají i další autoři. Nyní zpracovávám podrobný návod, jak vyvíjet nové moduly pro moji aplikaci tak, aby byla zachována konzistence projektu. Pracuji také na nových modulech, které rozšíří webovou aplikaci i například o Sklad nebo Fakturaci. Modularita projektu umožní jednoduché nasazení nových modulů a úpravu podle potřeb. Tím šetří mnoho peněz, které by společnost musela vynaložit za mnohdy velice nákladný software. Aplikace může být samozřejmě využita i pouze jako doplňková k dalšímu specializovanému softwaru. Dalším krokem ve vývoji aplikace je například správa zdrojového kódu pomocí verzovacího nástroje Git.
Literatura [1] The Apache HTTP Server Project. http://httpd.apache.org/, stav z 05. 12. 2009. [2] Composite Application Guidance - Modularity. http://msdn.microsoft.com/en-us/library/cc707850.aspx, stav z 13. 12. 2009. [3] Definice: Webová aplikace. http://cs.wikipedia.org/wiki/Webov%C3%A1_aplikace, stav z 30. 12. 2009. [4] Frequency decoder - Unobtrusive Table Sort Script. http://frequency-decoder.com/2006/09/16/, stav z 21. 10. 2008. [5] Google Maps API Documentation. http://code.google.com/intl/cs/apis/maps/documentation/index.html, stav z 13. 12. 2009. [6] jQuery Javascript Library - Documentation. http://docs.jquery.com/Main_Page, stav z 8. 11. 2009. [7] jQuery plugin - Autocomplete. http://docs.jquery.com/Plugins/Autocomplete, stav z 1. 10. 2009. [8] jQuery plugin - ColorBox. http://colorpowered.com/colorbox/, stav z 1. 10. 2009. [9] jQuery plugin - idTabs. http://plugins.jquery.com/project/idTabs, stav z 1. 10. 2009. [10] SyncML - Synchronization Markup Language. http://en.wikipedia.org/wiki/SyncML, stav z 26. 11. 2009. [11] F. C.-T. M. B. Cristian Darie, Bogdan Brinzarea. AJAX a PHP: tvoříme interaktivní webové aplikace profesionálně. Zoner Press s.r.o, Brno, 1st edition, 2006. In Czech. [12] S. Holzner. Mistrovství v AJAXu. Computer Press s.r.o, Brno, 1st edition, 2007. In Czech. [13] D. Špinar. Tvoříme přístupné webové stránky. Zoner Press s.r.o, Brno, 1st edition, 2004. In Czech.
51
52
LITERATURA
Dodatek A
Seznam použitých zkratek AJAX Asynchronous Javascript And XML API Application Programming Interface CSS Cascading Style Sheets HTML HyperText Markup Language HTTP HyperText Transfer Protocol HTTPS HyperText Transfer Protocol Secure LDAP Lightweight Directory Access Protocol PHP PHP: Hypertext Preprocessor SSL Secure Socket Layer SQL Structured Query Language TCP Transmission Control Protocol TLS Transport Layer Security URL Uniform Resource Locator WWW World Wide Web XHTML eXtensible HyperText Markup Language XML eXtensible Markup Language .. .
53
54
DODATEK A. SEZNAM POUŽITÝCH ZKRATEK
Dodatek B
Instalační a uživatelská příručka
55
56
DODATEK B. INSTALAČNÍ A UŽIVATELSKÁ PŘÍRUČKA
B.1 B.1.1
Instalační příručka Co je potřeba pro běh aplikace
Než začnete aplikaci instalovat, zkontrolujte co je potřeba pro správnou funkčnost: • přístup k webovému serveru • podporu PHP verze alespoň 4.3 • MySQL databázi verze alespoň 4.1 • váš oblíbený internetový prohlížeč • případně textový editor (například PSPad, zdarma)
B.1.2
Instalace aplikace
Instalaci aplikace zvládnete za pomoci tohoto seznamu úkolů: • stahněte a rozbalte balík Opentis z adresy http://opentis.com • pokud nemáte MySQL databázi, založte ji, stejně jako MySQL uživatele s oprávněním přístupu a změn • pomocí FTP klienta nahrajte soubory z Opentis balíku na server • otevřete internetový prohlížeč a vepište adresu http://example.com/install/install.php (example.com zaměňte za URL adresu vašeho serveru) • následujte instrukce v prohlížeči • Opentis je nainstalován!
B.2
Uživatelská příručka
Moje aplikace se neustále vyvíjí a proto není vhodné uvádět zde uživatelskou příručku, která by byla neměnná. Vždy aktuální uživatelská příručka je umístěna na Internetu na adrese http://opentis.com
Dodatek C
Obsah přiloženého DVD Obsah DVD přiloženého k diplomové práci: \index.html
