Na tomto místě bude oficiální zadání vaší práce

Na tomto místě bude oficiální zadání vaší práce • Toto zadání je podepsané děkanem a vedoucím katedry, • musíte si ho vyzvednout na studiijním oddělení Katedry počítačů na Karlově náměstí, • v jedné odevzdané práci bude originál tohoto zadání (originál zůstává po obhajobě na katedře), • ve druhé bude na stejném místě neověřená kopie tohoto dokumentu (tato se vám vrátí po obhajobě).

i

ii

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačové grafiky a interakce

Bakalářská práce

Webový docházkový systém Roman Václavík

Vedoucí práce: Mgr. Petr Matyáš

Studijní program: Softwarové technologie a management, Bakalářský Obor: Web a multimedia 8. června 2009

iv

v

Poděkování Na tomto místě bych rád poděkoval hlavně Mgr. Petru Matyášovi, vedoucímu této bakalářské práce, za jeho čas, ochotu a cenné rady, které mě nasměrovaly k zdárnému dokončení této práce. Rovněž bych chtěl poděkovat své rodině za jejich podporu během celého studia.

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).

V Praze dne 8. 6. 2009

.............................................................

viii

Abstract This bachelor work describes analysis, design and implementation of the web-based system for the evidence of the attendance. Application serves to save human and financial resources for the recording and subsequent evaluation of attendance. The employees identify themselves at the terminal station using their card with the barcode. Logged users can perform in the system only those actions, for which they have assigned right by administrator. Part of this work is also testing the user interface and functionality of the system.

Abstrakt Tato bakalářská práce se zabývá analýzou, návrhem a implementací webového docházkového systému. Aplikace slouží k ušetření lidských a finančních zdrojů při zaznamenávání a následném vyhodnocování docházky. Zaměstnanci se identifikují u terminálu pomocí karet s čárovým kódem. Přihlášení uživatelé mohou v systému provádět jen ty akce, na které jim bylo přiděleno administrátorem právo. Součástí práce je rovněž testování uživatelského rozhraní a funkcionality systému.

ix

x

Obsah Úvod

1

1 Popis práce 1.1 Popis řešeného problému . . . . . . . . . . . . . . . . 1.1.1 Cíle práce . . . . . . . . . . . . . . . . . . . . 1.1.2 Katalog požadavků . . . . . . . . . . . . . . . 1.1.2.1 Funkční požadavky . . . . . . . . . 1.1.2.2 Obecné požadavky . . . . . . . . . . 1.1.3 Požadavky na hardware . . . . . . . . . . . . 1.1.4 Požadavky na software . . . . . . . . . . . . . 1.2 Rešerše . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 Docházkový systém InTagral – Program AME 1.2.2 Docházkový systém ANeT . . . . . . . . . . . 1.2.3 Docházkový systém Z-WARE . . . . . . . . . 1.2.4 Docházkový systém MersitePresence2 . . . . 1.2.5 Shrnutí . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

3 3 3 3 3 4 5 5 6 6 7 7 8 9

. . . . . . . . . . . . . . . . .

11 11 11 13 14 14 16 16 16 17 17 17 18 18 19 19 19 19

2 Analýza a návrh práce 2.1 Analýza . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Funkcionalita systému . . . . . . . . . . . . . 2.1.2 Technologie pro naprogramování aplikace . . 2.1.2.1 Aplikační vrstva . . . . . . . . . . . 2.1.2.2 Prezentační vrstva . . . . . . . . . . 2.1.2.3 Datová vrstva . . . . . . . . . . . . 2.1.3 Postupy implementace . . . . . . . . . . . . . 2.1.3.1 Sekvenční metodiky . . . . . . . . . 2.1.3.2 Iterační metodiky . . . . . . . . . . 2.1.4 Použití frameworků či jiných hotových řešení 2.1.4.1 Frameworky . . . . . . . . . . . . . 2.1.4.2 MVC architektura . . . . . . . . . . 2.1.4.3 Hotová řešení . . . . . . . . . . . . . 2.1.5 Časový odhad . . . . . . . . . . . . . . . . . . 2.2 Návrh . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 Technologie pro naprogramování aplikace . . 2.2.1.1 Aplikační vrstva . . . . . . . . . . .

xi

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

xii

OBSAH

2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8 2.2.9

2.2.1.2 Prezentační vrstva . . . . . . 2.2.1.3 Datová vrstva . . . . . . . . Konvence . . . . . . . . . . . . . . . . Postup implementace . . . . . . . . . . Použití frameworku a hotových řešení Časový odhad na základě návrhu . . . Datový model . . . . . . . . . . . . . . Diagram případů užití . . . . . . . . . Sekvenční diagram . . . . . . . . . . . Grafika . . . . . . . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . .

19 20 20 22 22 23 23 25 25 25

3 Popis implementace 3.1 Použitý software . . . . . . . . . . . . 3.2 Postup implementace . . . . . . . . . . 3.3 Struktura aplikace . . . . . . . . . . . 3.3.1 Hlavní obsluha . . . . . . . . . 3.3.2 Model . . . . . . . . . . . . . . 3.3.3 Controller . . . . . . . . . . . . 3.3.4 View . . . . . . . . . . . . . . . 3.3.5 Moduly . . . . . . . . . . . . . 3.3.6 Podpůrné skripty . . . . . . . . 3.4 Speciální skripty . . . . . . . . . . . . 3.4.1 Skript pro zpracování docházky 3.4.2 Výpočet mzdy . . . . . . . . . 3.4.3 Generování čárového kódu . . . 3.4.4 Export docházky zaměstnanců 3.5 Nastavení aplikace . . . . . . . . . . . 3.5.1 Internet vs. intranet . . . . . . 3.5.2 Nastavení pro správce . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

27 27 27 29 29 30 30 31 31 32 33 33 34 34 35 35 35 36

4 Testování 4.1 Testování funkčnosti . . . . . . . 4.1.1 Jednotkové testy . . . . . 4.1.2 Testy akcí v prohlížeči . . 4.2 Testování uživatelského rozhraní 4.2.1 Kognitivní průchod . . . . 4.2.2 Test použitelnosti . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

. . . . . .

37 37 37 39 40 40 41

. . . . . .

. . . . . .

. . . . . .

Závěr

45

Literatura

47

A Seznam použitých zkratek

49

B Nastavitelné vlastnosti modelu

51

C Datový model

53

OBSAH

D UML D.1 Případy užití . . . . D.1.1 Diagram . . . D.1.2 Scénáře . . . D.2 Sekvenční diagramy

xiii

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

55 55 55 57 60

E Ukázky aplikace

69

F Instalační manuál

73

G Uživatelský manuál 75 G.1 Pro zaměstnance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 G.2 Pro uživatele, kteří nemají pouze práva pro zaměstnance . . . . . . . . . . . . 78 H Obsah přiloženého CD

81

xiv

OBSAH

Seznam obrázků 2.1

MVC architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.1

Ukázka kalendáře . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1

Ukázka testu v programu Selenium IDE . . . . . . . . . . . . . . . . . . . . . 39

C.1 Datový model systému – část 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 53 C.2 Datový model systému – část 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 54 D.1 D.2 D.3 D.4 D.5 D.6 D.7 D.8 D.9

Případy užití – interakce se systémem . . . . . Sekvenční diagram – životní cyklus aplikace . . Sekvenční diagram – načítání relací . . . . . . . Sekvenční diagram – výběr akce . . . . . . . . . Sekvenční diagram – načtení seznamu záznamů Sekvenční diagram – načtení detailu záznamu . Sekvenční diagram – smazání záznamu . . . . . Sekvenční diagram – práce s formulářem . . . . Sekvenční diagram – načtení dat pro formulář .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

56 61 62 62 63 64 65 66 67

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

Ukázka Ukázka Ukázka Ukázka Ukázka Ukázka Ukázka

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

69 69 70 70 71 71 72

G.1 G.2 G.3 G.4 G.5

Uživatelský Uživatelský Uživatelský Uživatelský Uživatelský

vzhled aplikace . . . . . . přihlášení do aplikace . . navigační lišta . . . . . . filtr a řazení v seznamech stránkování . . . . . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

75 76 77 77 78

aplikace aplikace aplikace aplikace aplikace aplikace aplikace

– – – – – – –

přihlášení . . . . . . . . . karta zaměstnance . . . . terminál . . . . . . . . . . formulář . . . . . . . . . seznam záznamů . . . . . detail záznamu . . . . . . výplatní list zaměstnance

manuál manuál manuál manuál manuál

– – – – –

xv

. . . . . . .

xvi

SEZNAM OBRÁZKŮ

Seznam tabulek 2.1

Zaznamenávání docházky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 3.2 3.3

Počítání docházky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Výpočet nemocenských dávek . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Struktura čárového kódu EAN-13 . . . . . . . . . . . . . . . . . . . . . . . . . 35

B.1 Vlastnosti modelu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

xvii

xviii

SEZNAM TABULEK

Úvod Již zhruba 3 roky pracuji v oblasti webových technologií, proto pro mě bylo rozhodování o tématu bakalářské práce relativně snadné. Přesněji řečeno, oblast byla jasná, naimplementovat nějaký webový systém. Nad konkrétním systémem jsem trochu váhal. Nakonec jsem zvolil webový docházkový systém, i když jsem původně chtěl naprogramovat internetový obchod (eshop). Učinil jsem tak, protože na trhu už není místo pro nový eshop. Dále zde není prakticky možné vymyslet něco nového, co již dávno někdo jiný neimplementoval. A v neposlední řadě, eshopy jsou v poměrně velkém počtu dostupné jako open-source (volně k používání) řešení. Naproti tomu docházkových systémů na internetu není mnoho a hlavně se takřka nevyskytují ve formě open-source. U vytváření takového systému je ještě pořád relativně hodně míst, která jdou vylepšit oproti konkurenci. Mezi tato místa patří např. provozování systému ve více jazycích, zpřístupnění celé aplikace přes webové rozhraní nebo zaměření produktu na menší a střední firmy. Docházkový systém je aplikace, která by měla minimálně zaznamenávat docházku zaměstnanců na terminálech, spravovat informace o zaměstnancích a ve formě libovolného výstupu předat odpracovanou dobu jednotlivých zaměstnanců. U terminálu dochází k identifikaci zaměstnance. Identifikace může probíhat různými způsoby od zadání unikátního kódu přes bezkontaktní čipy až po snímání biometrických údajů zaměstnance. Tento systém nahrazuje ruční způsoby zaznamenávání docházky a poskytuje automatické počítání odpracovaných hodin, přesčasů, svátku, atd. Díky tomu dochází k úspoře ve výdajích za následné počítání docházky pověřenou osobou, jelikož aplikace to zpracuje vše sama během několika sekund.

1

2

ÚVOD

Kapitola 1

Popis práce 1.1 1.1.1

Popis řešeného problému Cíle práce

Cílem práce je vytvořit docházkový systém. Systém bude naimplementován pomocí webových technologií a bude postaven na frameworku, který dodržuje MVC architekturu. Bude zaměřen na menší podniky a samozřejmě bude dodržovat všechny bezpečností zásady. Dále jej bude možné snadno rozšířit o novou funkcionalitu (moduly). Systém bude po úspěšné implementaci důkladně otestován. Testování bude probíhat také během implementace, a to vždy, jakmile bude dokončen určitý blok práce. Nakonec bude vytvořena k této práci dokumentace, která si klade za cíl zmapovat všechno dění od zvolení tématu přes implementaci systému až po následné shrnutí dosažených výsledků. Výsledkem tedy bude funkční docházkový systém spolu s dokumentací, která popisuje a vysvětluje zvolené řešení implementace.

1.1.2 1.1.2.1

Katalog požadavků Funkční požadavky

• Systém slouží primárně jako náhrada papírových docházkových lístků. • Správa zaměstnanců ve firmě (založení nového zaměstnance, úprava či vymazání). • Výběr z několika desítek práv, na základě kterých může uživatel v aplikaci vykonávat dané akce. • Nastavení formátu data a času, zaokrouhlování hodin a dnů, různých přerušení pracovní doby a příplatků pro přesčasy, víkendy a svátky + jejich automatické připočtení ke mzdě. • Možnost zadat čas, za který automaticky vyprší doba přihlášení uživatele. • Definice organizační struktury firmy, směn, pracovních dob, svátků a slev na dani.

3

4

KAPITOLA 1. POPIS PRÁCE

• Generování čárových kódů ve formátu EAN-13. • Zobrazování jen aktuálně dostupných akcí v terminálu na základě předchozí akce. • Okamžité nebo zpětné zjištění přítomnosti zaměstnanců na pracovišti. • Možnost ručně změnit získané údaje z terminálů. • Zpracování mzdových podkladů + vygenerování výplatního listu ve formátu PDF. • Mzdové podklady se mohou nacházet ve čtyřech různých stavech (neúplné, zpracováno, zkontrolováno, schváleno). • Detailní přehledy o práci všech zaměstnanců, případně pouze zaměstnanců z daného oddělení, ve formátu CSV. • Zaznamenávání činností v systému do logu. • Možnost stránkování, filtrování a řazení záznamů v seznamech. • Validace formulářů. • Vícejazyčnost. 1.1.2.2

Obecné požadavky

• Systém bude naprogramován jako modulární webová aplikace: – použití skriptovacího jazyka PHP, – použití databáze MySQL, – použití šablonovacího systému Smarty (XHTML,CSS), – použití JavaScriptu. • Aplikace, běžící na serveru, bude přístupná pouze na intranetu nebo internetu (kvůli přístupu např. z domova). • Systém bude běžet nonstop. • Systém bude možné lehce rozšířit pomocí modulů. • Bezpečnost: – přístup pouze pomocí uživatelského jména a hesla, – omezená práce v aplikaci v závislosti na právech přihlášeného, – logování přihlášení (úspěšných i neúspěšných), – logování významných akcí v aplikaci. • Uživatelské požadavky: – přehledné a intuitivní ovládání,

1.1. POPIS ŘEŠENÉHO PROBLÉMU

5

– rychlost aplikace, – 100% funkčnost v prohlížeči Mozilla Firefox, – v dalších nejpoužívanějších prohlížečích (Internet Explorer, Opera) mohou nastat drobné odchylky v grafice oproti Firefoxu, – zobrazování chybových a informačních zpráv.

1.1.3

Požadavky na hardware

Požadavky na hardware jsou pro většinu uživatelů naprosto bez problémů splnitelné. Samotná aplikace pro svůj běh potřebuje jen počítač (server) a připojení k internetu (intranetu). Uživatelé, kteří chtějí se systémem pracovat, musí mít počítač, připojení k internetu (intranetu), monitor, klávesnici a myš. A nakonec pro terminál je potřeba počítač, připojení k internetu (intranetu), čtečka čárových kódů a monitor. Na konfiguraci počítače nejsou kladeny žádné velké požadavky. V podstatě jde jen o to, aby v případě terminálu nebo práce se systémem počítač zvládl otevřít internetový prohlížeč. U počítače, na kterém poběží aplikace, jsou nároky o něco větší. Je potřeba, aby zde byl neustále spuštěn software, který je potřebný pro běh aplikace. Dále by měl být dostatečně výkonný na to, aby uživatelé přistupující k systému nemuseli čekat dlouho na odpověď serveru. Pro server a terminál je vhodné pořídit záložní zdroj jako ochranu před výpadkem dodávky elektrické energie. Bez elektrické energie totiž aplikace nepoběží a bylo by nutné docházku zaznamenat ručně a poté zpětně vložit do aplikace. Na rychlosti připojení k internetu nezáleží vůbec. Samozřejmě, čím vyšší bude, tím bude práce s aplikací rychlejší a příjemnější. Navíc je aplikace nakódována tak, že používá minimum obrázku s minimální velikostí. Monitor by měl mít minimální rozlišení 800x600 px. Navíc pro terminál je potřeba dotykový monitor, případně monitor s dotykovou fólií. V případě nouze, lze použít i klasickou myš, ale pak už není práce s terminálem tak pohodlná a příjemná. Čtečka čárových kódů musí podporovat emulaci klávesnice a musí dokázat načíst čárový kód typu EAN-13.

1.1.4

Požadavky na software

V případě serveru je potřeba zvolit takový operační systém, na kterém může běžet Apache, PHP 5 a MySQL podporující úložiště InnoDB. Nejpoužívanějšími systémy jsou Linux a Microsoft Windows. Je doporučeno zajistit si na serveru automatické zálohování aplikace, především databáze, pomocí nějakého softwaru na pravidelné zálohy či napsáním vlastního skriptu. Pro terminál nebo práci s aplikací je potřeba libovolný operační systém, ve kterém lze spustit internetový prohlížeč. Aplikace je odladěna v prohlížeči Firefox, nicméně i v ostatních nejpoužívanějších prohlížečích funguje aplikace bez problémů, i když se mohou vyskytnout drobné grafické odlišnosti.

6


1.2

Rešerše

Před začátkem analýzy a návrhu práce je vždy dobré prozkoumat trh. Lépe řečeno, najít konkurenční produkty. A to jak s podobnou cílovou skupinou a funkcionalitou pro porovnání, tak i odlišné pro inspiraci.

1.2.1

Docházkový systém InTagral – Program AME

• Domovské stránky produktu: www.iresoft.cz [18]. • Technické parametry: – možnost nadefinovat neomezený počet zaměstnanců, – několik typů tiskových sestav (např. příchody a odchody, mzdové listy) s možností uložení sestav do souboru PDF či Microsoft Excel, – libovolně definovatelný směnný provoz – pevné a pružné směny, vícesměnné provozy, – výpočty příplatků – svátky, SO+NE, odpolední a noční směna, – automatický odpočet přestávek, – evidence až pěti příchodů a odchodů za den, 12 typů přerušení pracovní doby, – evidence až dvou výjimek za den – dovolená, nemoc, lékař, atd., – přenosy mezi měsíci – převod přesčasových hodin do dalšího měsíce, – možnost automaticky vygenerovat příchody a odchody, – síťový provoz včetně autorizace uživatele při přihlášení do aplikace. • Moduly: – AME-Terminal (programová náhrada docházkového terminálu pro zaměstnance, kteří ke své práci využívají počítač), – AME-Monitor (správa čtečky), – AME-Rozpis (plánování směn pracovníků na pracovišti s nepřetržitým nebo vícesměnným provozem). • Výhody: – snadno rozšiřitelná aplikace díky modulům, – aktualizace programu přes internet, – velké množství různých tiskových sestav, – 4 možnosti pro zaznamenávání docházky. • Nevýhody: – nepodporuje více jazyků, – nepřehledné ovládání, – platformě závislé.

1.2. REŠERŠE

1.2.2

Docházkový systém ANeT

• Domovské stránky produktu: www.anet.info [16]. • Technické parametry: – hromadné změny středisek a modelů pracovní doby, – hromadné zpracování pracovních listů, – plánování absencí a směn za středisko, – dovolená: nárok roční/měsíční, převod, – sledování přítomnosti pracovníků za středisko, – reporty a statistiky. • Moduly: – týdenní režimy, – služební cesty, – nákladová střediska, – pohotovosti, – vyrovnávací období, – uživatelské statistiky, – stravenky. • Výhody: – snadno rozšiřitelná aplikace díky velkému počtu modulů, – hotové balíčky pro všechny typy firem (od malých přes střední až po velké), – možnost sledování údajů přes webové rozhraní. • Nevýhody: – nepodporuje více jazyků.

1.2.3

Docházkový systém Z-WARE

• Domovské stránky produktu: www.z-ware.cz [17]. • Technické parametry: – volitelné zaokrouhlení docházkových kont, – víceúrovňový systém přístupových práv v síťové i lokální verzi, – okamžitý přehled o přítomnosti, – zpětný přehled o přítomnosti – zjištění kdo a kdy byl přítomen, – sledování průchodů vybraným terminálem, – hlídání průchodu vybrané osoby,

7

8


– automatický záznam přestávek, – možnost ručního označování přestávek na terminálu, – monitorování ručně provedených změn a oprav, – možnost definování vlastních rozvrhů pracovní doby, – až čtyřúrovňové členění struktury firmy, – automatické ukončování neúplných záznamů, – individuální definice svátků a výjimečných dnů, – přenos přesčasů, – automatický výpočet příplatků, – schvalování a podepisování údajů oprávněnou osobou, – export libovolných dat ze systému do formátu PDF, DOC, XLS, XML. • Moduly: – Vrátnice (možnost evidence návštěv), – Vozidla (správa a evidence údajů o firemních vozidlech), – Personální (možnost vedení personální agendy jednotlivce). • Výhody: – snadno rozšiřitelná aplikace díky modulům, – možnost sledování údajů přes webové rozhraní. • Nevýhody: – nepodporuje více jazyků, – platformě závislé.

1.2.4

Docházkový systém MersitePresence2

• Domovské stránky produktu: www.mersite.cz [19]. • Technické parametry: – možnost exportů mzdových podkladů do Microsoft Excel, – on-line komunikace s docházkovými terminály, – automatická aktualizace a nastavení času na terminálech, – výpočet přesčasů, práce s přesčasovými konty, – přehled nároku na stravenky, – automatický výpočet svátků včetně pohyblivých, jako jsou Velikonoce, – neomezený počet důvodů přerušení pracovní doby.

1.2. REŠERŠE

9

• Moduly: – nejsou, aplikace se případně upravuje podle potřeb zákazníka. • Výhody: – snadno rozšiřitelná aplikace díky modulům, – 3 možnosti pro zaznamenávání docházky. • Nevýhody: – nepodporuje více jazyků, – platformě závislé, – neumožňuje prohlížení docházky přes webové rozhraní.

1.2.5

Shrnutí

Z těchto čtyř zkoumaných docházkových systémů se stal jednoznačným vítězem ANeT. Má předpřipravené řešení pro všechny typy firem. Není problém doplnit systém o další moduly. Dokonce tento systém funguje i přes webové rozhraní, i když nelze vykonávat úplně všechny operace, co v klasické aplikaci. Jedinou nevýhodou, co jsem u tohoto systému zpozoroval, je nepodporování více jazyků. Pro další vývoj mého docházkového systému budu především brát na zřetel právě aplikaci firmy ANeT. Ale s tím, že má cílová skupina jsou primárně menší a případně střední firmy. Čili se budu snažit tlačit náklady na hardware směrem dolů. Z toho vyplývá použití klasické čtečky čárových kódů. Dále by aplikace měla být dostupná odkudkoliv (tzn. webová), kde je připojení k internetu, pokud tomu tak správce aplikace dovolí. Vícejazyčnost bude výhodou, jelikož se dnes často setkáváme na pracovištích s lidmi různých národností.

10


Kapitola 2

Analýza a návrh práce 2.1 2.1.1

Analýza Funkcionalita systému

Z výše uvedeného katalogu požadavků vyplývá poměrně jasná funkcionalita, kterou se pokusím zanalyzovat v dalších odstavcích. Systém má za cíl nahradit dosud používané ruční zaznamenávání docházky. Při tomto způsobu může docházet k určitým nepřesnostem v odpracovaných hodinách. Nejlépe to osvětlí následující tabulka. Akce Příchod Začátek přestávky Konec přestávky Odchod

Skutečný čas 8:06 11:57 12:32 15:56

Zapsaný čas 8:00 12:00 12:30 16:00

Rozdíl 0:06 0:03 0:02 0:04

Tabulka 2.1: Zaznamenávání docházky Zaměstnanec tedy ošidil zaměstnavatele o 15 minut. Vypadá to sice jako zanedbatelná položka, ale ve výsledku za měsíc to dává 15 minut * 22 pracovních dnů = 330 minut, což je 5,5 hodiny. Když má firma 10 zaměstnanců, tak zaměstnavatel zaplatí všem zaměstnancům 55 hodin navíc (při hodinové mzdě 200 Kč/hod se jedná o částku přes 10 000 Kč měsíčně). Při použití docházkového systému tyto rozdíly nevznikají, jelikož je zaznamenáván přesný čas akce včetně sekund a zaměstnanec to nemůže nijak ovlivnit. K zaokrouhlení dojde až při měsíčním vyúčtování, kdy je docházka zpracována a zaokrouhlí se tedy jako celek. Aplikace má také na starosti správu zaměstnanců. Udržuje základní informace o zaměstnanci, jako je např. jméno, příjmení, adresa, telefon, atd. Informace, které se mohou měnit v čase a jsou relevantní pro výplatní list, se archivují a mají vždy danou platnost. Zaměstnanec je rovněž zařazen do oddělení firmy a má přiřazenou pracovní dobu, pracovní směnu a pracovní pozici. Nedílnou součástí informací o zaměstnanci je nastavení platu a odměn. A v neposlední řadě je potřeba uchovávat textovou podobu čárového kódu zaměstnance a zároveň musí být umožněno tento kód vygenerovat pro následnou manipulaci s ním.

11

12

KAPITOLA 2. ANALÝZA A NÁVRH PRÁCE

Zaměstnanci se u terminálu nejprve musí identifikovat pomocí kartičky s čárovým kódem, kterou jim vystavil zaměstnavatel. Po úspěšné identifikaci se zaměstnanci zobrazí dostupné akce. Ty se zobrazují dynamicky vždy podle předchozí provedené akce. Pokud není aktivní žádná předchozí akce, zobrazí se zaměstnanci všechny možnosti. K terminálu lze přistupovat i bez identifikace. K tomu je ale potřeba být přihlášený v aplikaci a mít patřičné práva. Veřejný terminál (s identifikací podle čárového kódu) je dostupný pouze z jedné IP adresy. Zabrání se tak přístupu zvenčí, díky čemuž se zamezí náhodnému zkoušení zadávání textové podoby čárového kódu a následné manipulaci s docházkou daného zaměstnance. Pokud chce zaměstnavatel umožnit zaměstnanci přístup do aplikace, musí pro něj vygenerovat uživatelský účet a nastavit mu patřičná práva, která umožňují přihlášenému uživateli vykonávat dané akce. Mzdové podklady zaměstnanců se generují každý druhý den v měsíci vždy pro předchozí měsíc pomocí Cronu. Generování probíhá na základě údajů z terminálu, přičemž se automaticky vypočítávají přesčasy, víkendy, svátky, dovolené a nemocenské dávky. Podklady se mohou nacházet v různých stavech, které uživateli poskytují informaci, v jaké fázi zpracování jsou. Lze jim upravit všechny položky a nechat pak celý mzdový podklad na základě změněných políček přepočítat nebo jej jen uložit bez přepočítání. Na základě mzdových podkladů může uživatel mající patřičná práva vygenerovat výplatní list ve formátu PDF. Systém umožňuje zaměstnavateli (uživateli s potřebnými právy) kromě základních databázových operací (vytvořit, upravit, smazat, číst) nad modely aplikace definovat vlastní svátky, měnit formát data a času, nastavovat informace o firmě, zaokrouhlování hodin a dnů ve mzdových podkladech a manipulovat s možnostmi terminálu (např. přidávat nové typy přerušení pracovní doby). Může také nastavit dobu, za kterou má dojít k automatickému odhlášení přihlášeného uživatele. Systém dále nabízí kontrolu přítomnosti zaměstnanců na pracovišti ve zvoleném datu a čase, a to i zpětně. Pokud je uživatel v práci, ale zrovna má nějaké přerušení, systém nevypíše, že zaměstnanec není na pracovišti, ale že je momentálně mimo pracoviště + název přerušení. Tato funkce je prospěšná hlavně pro vrátného, který může hned zjistit, zdali je zaměstnanec v práci nebo ne, pokud se po něm někdo shání. Systém dovoluje uživateli se správnými právy exportovat detailní přehledy o práci zaměstnanců ve formátu CSV za zvolené období. Všechny důležité operace v aplikaci (typicky se jedná o přidání, úpravu a mazání záznamů) se logují. Log obsahuje danou událost včetně uživatelského jména, časovou značku a IP adresu, ze které byla akce vykonána. Log je dostupný uživatelům, kteří mají právo pro čtení logu. Nejde mazat ani upravovat z důvodu zabránění účelovým manipulacím. Práce s aplikací by měla být co nejpřehlednější, intuitivní a co nejvíce nápomocna uživateli. Z toho důvodu je zvolena střídmá a jednoduchá grafika, která jasně čleňí stránku na čtyři části – hlavičku, menu, zobrazovací plochu a patičku. Dále je použito stránkování, filtrování a řazení při procházení záznamů, což dovoluje uživateli poměrně elegantně, přesně a rychle najít to co hledá. Při vkládání nebo úpravě záznamu je uživateli k dispozici validátor, který formulář zkontroluje a vrátí případné chyby. Chyby jsou jasně specifikovány a nemůže tak dojít ke zmatení uživatele. Popis chyby se skládá z názvu chybně vyplněného pole a popisu chyby, čili co je špatně a co se očekává za hodnotu. Uživateli jsou zobrazovány chybové (červené pozadí) a informační (žluté) zprávy po vykonání nějaké akce. Např. při vložení nového záznamu dostane uživatel informační zprávu o tom, že byl záznam úspěšně přidán. Naopak

2.1. ANALÝZA

13

při pokusu načíst detail nějakého záznamu s neplatným identifikátorem dostane chybovou zprávu o tom, že záznam nemohl byt načten z důvodu zadání neplatného identifikátoru. Aplikace generuje vlastní chybové stránky, které poskytují uživateli základní informace o tom, co se děje a proč se ocitl na chybové stránce. Přesněji řečeno jsou připraveny stránky pro chybové kódy 401 (stránka vyžaduje přihlášení), 403 (nedostatečná práva pro přístup na stránku) a 404 (stránka nenalezena). Systém může být vícejazyčný, počet jazyků není omezen. Pro každý nový jazyk je potřeba udělat překlad statických textů aplikace.

2.1.2

Technologie pro naprogramování aplikace

Před započetím samotné implementace je potřeba se rozhodnout jaké se použijí technologie. Výběr správných technologií může značně ulehčit vývoj aplikace a naopak výběr nesprávných technologií může vývoj značně časově protáhnout. V současné době je na světě mnoho programovacích jazyků a technologií. Některé jsou velmi podobné a liší se jen v detailech, jiné se mohou diametrálně lišit. Pro správný výběr je potřeba vzít v úvahu několik věcí a na základě nich se poté rozhodnout. Hlavní rozhodovací faktory jsou: • Na jakém hardwaru aplikace poběží? • Na jakém operačním systému bude aplikace běžet? • Jaká má být rychlost aplikace? • Dostupnost aplikace přes internet (webová aplikace). • Jaká je požadovaná úroveň zabezpečení? • Placené či neplacené technologie? • Při použití více technologií (skoro každá aplikace pracuje s více technologiemi) zkontrolovat vzájemnou komptabilitu. • Jaká je podpora (dokumentace, příklady, fóra) k dané technologii? Samozřejmě je jich ještě celá řada, ale alespoň tyhle by měly být brány v potaz, aby mohl být zaručen hladký vývoj aplikace. V mém rozhodování ohledně technologií se zúžil výběr pouze na webové technologie, protože tématem mé práce je webový docházkový systém. Okruh hledání lze rozdělit na tři části (třívrstvá architektura – MVC): • aplikační vrstva, • prezentační vrstva, • datová vrstva.

14

2.1.2.1


Aplikační vrstva

Aplikační vrstva se dá považovat za mozek celé aplikaci. Od ní se odvíjí výběr technologií pro prezentační a datovou vrstvu. Proto je potřeba volit uvážlivě. PHP Hypertextový preprocesor je skriptovací jazyk, který slouží pro tvorbu dynamických stránek. Na základě požadavku od klienta se zpracuje daná událost na straně serveru, který následně odešle klientovi výsledek požadavku. Od verze 5 navíc podporuje objektové programování, což uvítala většina programátorů. Mezi výhody patří nezávislost na platformě, podpora mnoha databázových systémů, svobodná licence pro používání, vynikající podpora a rozšířenost u hostingových společností. Naopak nevýhody jsou chybějící debugovací (ladící) nástroj ve standardní distribuci, neexistující definice jazyka, nekonzistentní pojmenování funkcí, nejednotné pořadí parametrů a neustálé překládání skriptu při každém požadavku [25] [10] [14]. Java EE Je součást platformy Java určená pro tvorbu webových aplikací. Java je objektově orientovaný jazyk, který je relativně jednoduchý, nezávislý na platformě, přenositelný, bezpečný a robustní. Nevýhodou je pomalejší start aplikace a větší paměťová náročnost, která se projevuje hlavně u jednodušších aplikací [7]. ASP.NET Je soubor webových technologií patřící do .NET Frameworku od firmy Microsoft. Nahrazuje zastaralý ASP, ale kromě názvu toho nemají moc společného. ASP.NET je založen na CLR, který je sdílen všemi aplikacemi postavenými na .NET Frameworku. Programátoři tak mohou realizovat své projekty v jakémkoliv jazyce podporujícím CLR, např. Visual Basic.NET, JScript.NET, C#, Managed C++, ale i mutace Perlu, Pythonu a další [5]. 2.1.2.2

Prezentační vrstva

Základním stavebním kamenem prezentační vrstvy je jazyk HTML, respektive XHTML a kolekce stylů pro grafickou úpravu stránky CSS. Existují ale i technologie, které usnadňují často zdlouhavé psaní HTML kódu a hlavně důsledně oddělují prezentační vrstvu od aplikační, tzv. šablonovací systémy. Navíc pro prezentační vrstvu existují skriptovací jazyky, které dovedou uživateli zvýšit komfort práce a interakci s aplikací. XHTML Je rozšiřitelný značkovací jazyk pro hypertext. Jedná se o převedení staršího jazyka HTML tak, aby vyhovoval podmínkám tvorby XML dokumentů a přitom byla zachována zpětná kompatibilita [11].

2.1. ANALÝZA

15

CSS Jedná se o jazyk, který popisuje jak se má stránka napsaná pomocí HTML či XHTML zobrazit v prohlížeči. Zároveň slouží k oddělení struktury od stylu dokumentu [6]. Smarty, HTMLTmpl, Master Pages, JSP, JSTL Šablonovací systémy slouží pro usnadnění práce s HTML kódem a hlavně oddělení prezentační vrstvy od té aplikační. Díky tomu lze práci jednoduše rozdělit mezi kodéry a programátory, přičemž se tyto dvě role vůbec neovlivňují. • Šablonovací systémy pro PHP – Smarty – robustní systém umožňující napsat si vlastní modifikátory či funkce. Nabízí širokou škálu vlastních značek připravených k použití v šablonách [15]. – HTMLTmpl – oproti Smarty je to „sirotek“. Obsahuje jen základní značky. Na druhou stranu nedává kodérovi do ruky tak silnou zbraň, jakou Smarty beze sporu je. • Šablonovací systémy pro ASP.NET – Master Pages – je zde jedna master page, která obsahuje společné elementy a dále má vyznačená místa, do kterých lze vkládat další obsah. Ostatní stránky (content pages) poté k master page doplňují pouze požadovaný obsah. Lze do sebe vnořovat i samotné master pages [9]. • Šablonovací systém pro Javu – JSP – jde vlastně o HTML stránky, do kterých lze vložit speciální tagy obsahující Java kód. – JSTL – je doplnění JSP o standardizovanou knihovnu tagů. K dispozici jsou tagy pro iterace, podmínky, větvení, atd. JavaScript Je objektově orientovaný, na platformě nezávislý, skriptovací jazyk. Vykonává se na straně klienta, čili v prohlížeči. Díky tomu lze měnit obsah stránky, aniž by se musela stránka znovu načíst (nedochází k odeslání požadavku serveru). Naproti tomu, díky této možnosti, nelze z bezpečnostních důvodů například pracovat se soubory (mohlo by dojít k ohrožení soukromí uživatele) [26] [8]. AJAX Rovněž umožňuje měnit obsah stránky bez nutnosti znovunačtení stránky. Ajax ve skutečnosti není konkrétní jednotlivá technologie, ale pojem označující použití několika technologií dohromady s určitým cílem [3]: • HTML (nebo XHTML) a CSS pro prezentaci informací, • JavaScript pro zobrazování a dynamické změny prezentovaných informací, • XMLHttpRequest pro asynchronní výměnu dat s webovým serverem (typicky je užíván formát XML, ale je možné použít libovolný jiný formát včetně HTML, prostého textu, JSON či EBML).

16


2.1.2.3

Datová vrstva

Jako úložiště dat může být zvolen buď obyčejný souborový systém (prosté textové soubory) nebo databáze (nejpoužívanější řešení). V případě souborového systému je potřeba vymyslet nějakou strukturu pro ukládání dat do souborů, tak aby se v tom dalo dobře orientovat a hlavně pracovat. U databázových systémů je výběr opravdu velký. Níže následuje výpis nejpoužívanějších a nejvíce vhodných databázových systémů vzhledem k výběru technologie pro aplikační vrstvu. Jde pouze o seznam bez popisu jednotlivých databází, jelikož ten by byl ve většině případů hodně podobný. • MySQL, • PostgreQL, • Oracle, • MSAccess.

2.1.3

Postupy implementace

Metodikami pro vývoj softwaru se zabývá disciplína zvaná softwarové inženýrství. Metodiky se dají rozdělit na dva „tábory“. Rozdělení a popis metodik je uveden níže. Při studiu této problematiky jsem použil knihu Agilní programování [27]. 2.1.3.1

Sekvenční metodiky

Tato metodika si klade za cíl postupovat podle předem zvoleného schématu, a to tak, že není dovoleno přeskakovat, ale musí se postupovat, tak jak plyne dané schéma. Schéma může vypadat například takto (postupuje se shora dolů): • analýza, • návrh, • implementace, • testování, • nasazení aplikace (případná údržba). Typickým příkladem této metodiky je vodopádový model (postup shora dolů, jako když teče vodopád). Přistupovat k následující fázi je dovoleno pouze, když je současná fáze splněna na 100%. Existují ale i různé modifikace vodopádového modelu, které např. dovolují vracet se o úroveň výše. V současné době se už moc nepoužívá, protože není příliš vhodná pro praxi. Problém je právě v onom postupu shora dolů při 100% splnění dané fáze. V praxi dochází v jednotlivých částech během vývoje ke změnám.

2.1. ANALÝZA

2.1.3.2

17

Iterační metodiky

Vychází ze starších, již roky prověřených, metodik. Jsou upraveny tak, aby vyhovovaly neustálým změnám jednotlivých fází vývoje. Vývoj probíhá v rámci několika iterací. V jedné iteraci dojde k průchodu celým schématem (analýza → návrh → implementace → testování). Tradiční Kladen velký důraz na funkčnost aplikace. Fixní položkou je funkcionalita. Čas a finance jsou proměnné položky. Patří sem například spirálový model, který se snaží řešit nedostatky vodopádového modelu. Používá tedy iterativní vývoj a hlavně důslednou analýzu rizik, které mohou nastat. Právě pravidelná analýza rizik snižuje pravděpodobnost neúspěchu. Problémem může být, že aplikace je uvolněna až na konci, během iterací je uvolňován pouze prototyp. Agilní Kladen velký důraz na rychlost vývoje aplikace. Fixními položkami jsou čas a finance. Funkcionalita je proměnná položka. Hlavním zástupcem je extrémní programování. Používá se tam, kde je limitovaný čas nebo finance, zákazník nezná přesné zadání či nad ním váhá, systém se bude časem měnit a členové týmu spolu dobře vycházejí. Naopak extrémní programování nebude fungovat, když je tým vývojářů početný (>15 osob), cyklus překlad → linkování → spuštění trvá několik minut a více nebo není možné dostat zákazníka na pracoviště. Postup vývoje v iteracích je následující: • plánování, • navrhování, • programování, • testování.

2.1.4 2.1.4.1

Použití frameworků či jiných hotových řešení Frameworky

Při tvorbě větších projektů se vyplatí použití frameworku, protože se jednotlivé kusy kódů opakují anebo jsou téměř totožné. Framework vytváří jakési rozhraní, které poskytuje správné třídy či funkce pro řešení mnoha běžných problémů při vývoji aplikací (např. práce s databází). Tímto je zaručena opakovatelná použitelnost kódu a hlavně programátorovi ušetří spoustu času se psaním zbytečného kódu (funkcionality zajištěné frameworkem). Framework tedy slouží jako základ při vývoji aplikace. Bývá pravidlem, že nutně dodržuje MVC architekturu. Obsahuje v sobě sadu návrhových vzorů (ověřené a ustálené postupy řešení běžných problémů) a velké množství potřebných knihoven. Výsledkem bývá čistá a přehledná aplikace za předpokladu, že programátor dokáže s frameworkem výborně pracovat.

18


Základní přehled frameworků pro PHP: • Zend, • CakePHP, • Symfony. Základní přehled frameworků pro Javu EE: • Struts, • Spring. Základní přehled frameworků pro ASP.NET: • ASP.NET WebForms, • ASP.NET MVC. 2.1.4.2

MVC architektura

Model-view-controller je softwarová architektura, která rozděluje aplikaci do tří nezávislých vrstev – prezentační (pohled), aplikační (řadič) a datová (model) vrstva. Díky oddělení těchto vrstev od sebe nezpůsobí úprava jedné vrstvy zásadní problémy v dalších (minimální vlivy ale mohou nastat) [4]. • Model (model) – doménově specifická reprezentace informací, s nimiž aplikace pracuje. • View (pohled) – převádí data reprezentovaná modelem do podoby vhodné k interaktivní prezentaci uživateli. • Controller (řadič) – reaguje na události (typicky pocházející od uživatele) a zajišťuje změny v modelu nebo pohledu. Na následujícím obrázku se nachází diagram, který zobrazuje vztahy mezi modelem, pohledem a řadičem. Plná čára znázorňuje přímou závislost, čárkovaná nepřímou. 2.1.4.3

Hotová řešení

Další užitečnou věcí při vývoji aplikací jsou již hotová řešení neboli knihovny. Knihovny může programátor využít tam, kde framework již nepostačuje nebo naopak má připravené řešení, ale programátorovi nevyhovuje. Knihoven je na webu mnoho. Některé jsou placené (zpravidla řeší velké problémy), jiné jsou ve formě open-source (zdarma při dodržení licenčních podmínek). Mívají různou velikost, od jednoho souboru až po desítky MB. Řeší problémy různých složitostí od vytváření dynamických menu přes generování dokumentů z jednoho formátu do druhého až po umělou inteligenci zastoupenou např. rozpoznáváním textů a objektů v obrázcích. V mé práci využiji hotových řešení pro generování PDF dokumentů z HTML kódu a vytvoření čárového kódu v určeném formátu. Na internetu je k těmto tématům řešení spousta, takže nic nebrání vyzkoušet pár nejlépe hodnocených a na základě otestování požadované funkčnosti si pak vybrat vhodného kandidáta.

2.2. NÁVRH

19

Obrázek 2.1: MVC architektura

2.1.5

Časový odhad

Na základě analýzy lze zhruba odhadnout potřebný čas pro zdárné ukončení práce (úvodní studie, analýza, návrh, implementace, testování a dokumentace). Pokud bude pro vývoj aplikace použit framework, který již zdatně ovládám, čas se bude pohybovat kolem 200 hodin. V případě, že framework zdaleka neovládám, bude výsledný čas kolem 300 hodin.

2.2 2.2.1

Návrh Technologie pro naprogramování aplikace

Jak bylo popsáno v analýze, výběr byl rozdělen do tří kategorií. 2.2.1.1

Aplikační vrstva

Aplikace bude napsána v jazyku PHP. A to z toho důvodu, že aplikace napsané v tomto jazyce budou fungovat na téměř každém hostingu. Další rozhodovací faktor byl zkušenost s danou technologií, kde PHP u mě jasně vítězí. Jazyk Java nebyl od začátku tak úplně ze hry. Ale pro potřeby aplikace je zbytečně robustní. Navíc vyžaduje speciální server, který není mezi dostupnými hostingy moc používán. Další věcí je rychlost odezvy aplikace, která by byla několikanásobně vyšší než v případě PHP. ASP.NET nebyl zvolen z podobných důvodů jako Java. Navíc s tímto jazykem nemám žádné zkušenosti, takže byl zamítnut prakticky hned na začátku. PHP bylo použito ve verzi 5.2.9-1. 2.2.1.2

Prezentační vrstva

Základem bude XHTML spolu s CSS. XHTML bylo zvoleno na úkor HTML, protože je novější a hlavně se snaží dodržovat jistou syntaxi, vycházející s XML. Dodržování těchto pravidel vede k větší přehlednosti kódu a zároveň výrazně zvyšuje šanci na podobné nebo

20


stejné zobrazení v různých prohlížečích, což je v dnešní době velmi důležité, jelikož prohlížečů je opravdu mnoho. Jako skriptovací jazyk na straně klienta bude použit JavaScript namísto AJAXu. Důvod je celkem prostý. AJAX je prakticky JavaScript s možností pracovat i na straně serveru. Jelikož tuto možnost ve své práci nevyužiji, je zbytečné používat robustnější AJAX místo jednoduššího JavaScriptu. Jelikož byl zvolen jazyk PHP pro aplikační vrstvu, výběr šablonovacího systému se zúžil na boj mezi Smarty a HTMLTmpl. Zde je volba obdobná jako v předcházejícím odstavci, akorát v opačném gardu. Smarty je robustnější než HTMLTmpl, proto bude pro účely práce vhodnější. Občas bude totiž potřeba použít syntaxi usnadňující práci, kterou HTMLTmpl nepodporuje (např. automatické vygenerovaní roletkového menu na základě pole s klíči a hodnotami). XHTML bylo použito ve verzi 1.0 Transitional, CSS ve 2.0, JavaScript ve 1.5 a Smarty ve 2.6.22. 2.2.1.3

Datová vrstva

Hned na začátku zvítězila databáze nad souborovým systémem. Prakticky se v dnešní době ani nic jiného nepoužívá (myšleno použití v aplikacích, kde se pracuje s dynamickými daty). Nyní zbývalo vyřešit už jen typ databázového systému. Jak bylo napsáno v analýze, výběr je opravdu velký. Vzhledem k přihlédnutí ke zvolenému jazyku pro aplikační vrstvu se do popředí dostaly systémy MySQL a PostgreSQL, které najdeme v nabídce většiny hostingů (MySQL ve větší míře). Nakonec bude použito MySQL, protože je v nabídce drtivé většiny hostingů, je zdarma, obsahuje poměrně velký počet typů úložišť a v neposlední řadě s ním mám velké a dobré zkušenosti [24] [13]. MySQL bylo použito ve verzi 5.1.32.

2.2.2

Konvence

Použití předem daných a jasných konvencí vede k přehlednějšímu a srozumitelnějšímu kódu. Proto je potřeba před začátkem implementace stanovit jasná pravidla toho, co a jak se bude psát. Hned na začátku je potřeba zmínit, že veškerý text bude psán v angličtině. Má to celkem prostý důvod. Angličtina je nejpoužívanější jazyk v technické sféře. Navíc se zde nevyskytují žádná sáhodlouhá povídání, takže překlad by neměl činit větší problém. Na druhou stranu je možné, že aplikaci budou upravovat jen lidé v rodném jazyce, tudíž se může zdát použití jiného jazyku jako zbytečnost, ale nikdy nelze dopředu vědět, kdo všechno bude aplikaci udržovat. Proto je angličtina poměrně jasná volba. Konvence v databázi: • všechny názvy jsou psány malými písmeny, • místo mezer v názvech jsou použita podtržítka, • z názvu by měl jasný patřičný význam,

2.2. NÁVRH

21

• název tabulky pro jádro systému začíná prefixem „core_“, • název tabulky pro modul systému začíná prefixem „modul_“, • název tabulky je psán v množném čísle, • primární klíč tabulky je psán ve formátu „id_“ + jednotné číslo názvu tabulky, • cizí klíč je pojmenován podle primárního klíče cizí tabulky, • vztahová tabulka typu N:M se pojmenovává podle formátu jméno první tabulky + „_has_“ + jméno druhé tabulky bez prefixu. Konvence pro PHP: • názvy souborů a složek jsou psány malými písmeny, • místo mezer v názvech souborů a složek jsou použity pomlčky, • jména proměnných, funkcí a metod mají počáteční písmeno malé, mezery nejsou, každé další slovo začíná velkým písmenem, • názvy tříd používají velbloudí konvenci, čili pro každé slovo je první písmeno velké, ostatní jsou malá, mezery nejsou, • akční metody třídy (metody, na které se odvolává přes URL) začínají prefixem „action“, • odsazení pomocí tabulátorů, • odsazování vnitřních bloků oproti nadřazenému bloku, • složené závorky jsou vždy na novém řádku. Konvence pro Smarty: • názvy souborů a složek jsou psány malými písmeny, • místo mezer v názvech souborů a složek jsou použity pomlčky, • jména proměnných mají počáteční písmeno malé, mezery nejsou, každé další slovo začíná velkým písmenem, • odsazení pomocí tabulátorů, • odsazování vnitřních bloků oproti nadřazenému bloku. Konvence pro značení statických textů: • značení se píše malými písmeny, přičemž mezery jsou nahrazeny podtržítky, • podle prefixu značení by mělo jít poznat, kam spadá statický text (např. „php_...“, „tpl_...“),

22


• prostřední část značení by měla obsahovat název souboru nebo název události, které se to týká, • poslední část značení říká, o jakou akci se jedná. Konvence pro značení práv: • značení se píše malými písmeny, přičemž mezery jsou nahrazeny podtržítky, • prefix značení je jméno tabulky, které se dané právo týká, • ve výjimečných případech může být prefix vynechán (typicky, když se právo nedotýká konkrétní jedné tabulky), • zbytek značení říká, o jaké právo k akci se jedná.

2.2.3

Postup implementace

Určitě nebudu postupovat podle sekvenčních metodik, a to právě kvůli jejich neduhu, kterým je sekvenční přístup ve vývoji. Očekávám totiž, že během vývoje bude docházet neustále k nějakým drobným korekcím. Z toho tedy vyplývá, že využiji služeb iteračních metodik. A celkem jasné je i vybrání přesnější sady metodik. Tou sadou jsou agilní metodiky na úkor metodik tradičních. A to z toho důvodu, že kladou důraz na čas namísto funkcionality. Ne že by bylo jedno, jakou bude mít aplikace funkčnost, ale funkcionalita se udělá taková, kterou lze za určitý čas zvládnout.

2.2.4

Použití frameworku a hotových řešení

Aplikace bude určitě postavena na frameworku. Otázkou ale zůstává, jaký framework vybrat a proč. Doposud jsem měl tu čest okusit CakePHP v rámci jedné primitivní aplikace. Framework mi opravdu ulehčil spoustu práce a psaní zbytečného kódu při implementaci. Ale také hodně přidělal, protože je potřeba se daný framework nejprve naučit, tak aby jej bylo možno se vší parádou použít. Toto zjištění mě přivedlo k nové myšlence, vytvořit si svůj framework. Framework bude tedy naprogramován vlastní. Časově vyjde vytvoření takového frameworku podobně jako naučení se již nějakého nového frameworku. Navíc to má výhodu v tom, že kód jsem tvořil sám, takže není problém případně něco lehce přidat nebo změnit, aniž by tím byla ovlivněna stávající funkčnost. Tyto modifikace se dělají u hotových frameworků poměrně těžko. Mínusem samozřejmě je dostupná funkčnost, která zdaleka není tak obrovská jako už u léta vyvíjených frameworků. Nicméně funkčnost by měla být naprosto dostačující, aby na tomto frameworku mohla být postavena kvalitní a provozuschopná aplikace. Pro generování PDF dokumentů z HTML kódu bude použita knihovna DOMPDF, která splňuje všechny požadavky – aplikace CSS stylů, možnost vkládání obrázků a podpora pro české znaky. Pro generování čárových kódů bude použita knihovna Barcode Generator, která splňuje prakticky jeden požadavek – vygenerování čárového kódu na základě jeho textové podoby ve formátu EAN-13. Navíc umožňuje generovat čárové kódy i v jiných formátech, což může být do budoucna velkou výhodou.

2.2. NÁVRH

2.2.5

23

Časový odhad na základě návrhu

Údaje z analýzy mohu jen potvrdit, s tím že je tedy potřeba vytvořit vlastní framework, což je o něco časově náročnější než naučení se frameworku. Takže časová náročnost by se měla pohybovat něco málo nad 300 hodinami.

2.2.6

Datový model

Níže následuje textový popis grafické reprezentace datového modelu (příloha C). Základní informace Název tabulky vždy začíná prefixem, který poskytuje informaci o typu tabulky – jádro systému (core_...) nebo modul (modul_...). Datový model je dále rozdělen do vrstev, které sdružují související tabulky, kvůli lepší orientaci. Vrstva systém Nachází se zde tabulky, které souvisejí s celým systémem. Tabulka core_settings obsahuje globální nastavení pro systém. Lze zde nastavit výchozí jazyk aplikace, který se nastaví v případě, že jej PHP samo nerozpozná. Dále základní údaje o firmě, formát data, formát času, měnu a dobu nečinnosti v sekundách, po které bude přihlášený uživatel automaticky odhlášen ze systému. Nakonec lze zvolit typ zaokrouhlování pro hodiny a dny ve mzdových podkladech. V tabulce core_languages se definují všechny jazykové mutace systému pomocí kódu jazyka (např. pro češtinu je to „cs“, pro angličtinu „en“, atd.). Všechny texty (statické i dynamické) se ukládají do tabulky core_texts. Každý záznam obsahuje informaci o jazykové mutaci (česká, anglická, atd.) a lokaci. Pro dynamický text to je jméno tabulky, id řádku v dané tabulce a typ textu. Pro statický text je relevantní pouze typ textu, zbylé dva atributy jsou pro všechny statické texty stejné. V systému je potřeba udržovat informace o svátcích v roce. K tomu slouží tabulka core_festivals, kde je uložen datum svátku ve formátu DD.MM a typ svátku. Typ svátku může být statický (každý rok je den svátku stejný) nebo dynamický (v každém roce je den jiný). V současné době je přidán pouze jeden dynamický typ, a to Velikonoce. Vrstva účty Jsou zde tabulky, které nesou informace potřebné k přihlášení a práci v systému. Informace o všech důležitých akcích v systému jsou archivovány v tabulce core_logs. Zaznamenává se akce (např. přidání nového zaměstnance) včetně uživatelského jména (pokud je uživatel přihlášen), datum a IP adresa, ze které byla vykonána daná akce. Přístupové údaje lidí do systému (přihlašovací jméno a heslo) jsou uloženy v tabulce core_accounts. Dále se zde definuje vazba na člověka (zaměstnance) a příznak, zda je daný přístupový účet aktivní či ne. Navíc byly přidány dva pomocné sloupce, které slouží k uchování informace o době, do kdy je uživatel přihlášen a dále k uložení jedinečného kódu pro přihlášeného uživatele, který slouží k identifikaci a ověření, zda jde opravdu o daného uživatele.

24


Všechna práva (možné interakce se systémem) jsou obsažena v tabulce core_rights. Zadávají se pomocí příslušného kódu a názvu práva (např. core_people_add – přidání nového člověka do firmy). Pro každý uživatelský účet se definuje seznam práv, která udávají, co může uživatel v systému provádět. Pro zaznamenání této vazby slouží tabulka core_accounts_has_rights. Vrstva docházka Sdružuje tabulky, týkající se zaměstnanců, sledování a plánování docházky. Tabulka, která uchovává základní informace o zaměstnancích, se nazývá core_people. Mimo jiné jsou zde informace o pracovní době, pracovní směně a zařazení do oddělení na pracovní pozici. Proměnné informace, které se promítají do mzdových podkladů, jsou uloženy v tabulce core_people_variable_data, kde mají vždy svou platnost (od – do). Toto rozdělení je provedeno z důvodu zpětného generování mzdových podkladů se správnými údaji o zaměstnanci. Tabulka core_quittances obsahuje odměny pro zaměstnance včetně základního platu za hodinu nebo měsíc. Pod pojmem odměny se zde vyskytují tyto položky – slevy na dani, hodinový příplatek za přesčasy, víkendy a svátky. Pracovní doby jsou definovány v tabulce core_working_times. Slouží pro nastavení počtu odpracovaných hodin za den. Na základě této hodnoty se poté vypočítávají přesčasy nebo přepočítává měsíční mzda. Hierarchická struktura firmy / pracovních pozic ve firmě je uložena v tabulce core_organization_structures / core_status_jobs. Vztah mezi pozicemi a odděleními ve firmě je definován v tabulce core_status_jobs_has_organization_structures. Pracovní směny ve firmě jsou uloženy v tabulce core_workshifts. Směnu, přesněji její interval, lze vytvořit poměrně přesně, a to až na konkrétní den, týden či měsíc. Pokud daný zaměstnanec nepracuje na směny, nastaví se interval pracovní doby na celý den. Tabulka, která zaznamenává veškerou docházku všech zaměstnanců, se jmenuje core_attendances. Ukládá se typ docházky, čas akce, typ akce (zda jde o začátek či konec) a samozřejmě vazba na zaměstnance. Typy docházky (i přerušení) jsou definovány v tabulce core_attendance_types (příchod od/odchod z práce, přestávka na oběd, odchod k lékaři, atd.). Vrstva identifikace zaměstnance Nachází se zde tabulky, které slouží k identifikaci zaměstnance u terminálu. Tabulka modul_identification_bar_codes uchovává data pro čtečku čárových kódů. Přesněji řečeno, je zde uložena vazba na zaměstnance a vygenerovaný čárový kód (jeho textová podoba). Vrstva mzdy Obsahuje tabulky potřebné ke mzdovým podkladům zaměstnanců. V tabulce modul_wages_employees_ledgers jsou archivovány informace potřebné k vygenerování mzdových podkladů zaměstnanců, a to i zpětně. Jsou zde uloženy hlavně účetní

2.2. NÁVRH

25

položky, jako např. odpracované hodiny, hrubá mzda, daň z příjmů, atd. Pak je zde ještě časová značka (rok a měsíc) a stav, který říká, v jakém stádiu se nachází zpracování mzdového podkladu.

2.2.7

Diagram případů užití

Jedná se o grafické znázornění poskytované funkčnosti aplikace z hlediska uživatele. V mém případě D.1.1 byli použiti tři aktéři (přihlášený uživatel, nepřihlášený uživatel a systém) a několik případů užití s využitím zahrnovacích (include) a rozšiřujících (extend) vazeb. Pro jednotlivé případy užití je k dispozici také scénář D.1.2.

2.2.8

Sekvenční diagram

Znázorňuje časové souvislosti mezi objekty, které si mezi sebou mohou posílat zprávy. V rámci bakalářské práce jsem vytvořil sekvenční diagramy D.2 pro životní cyklus aplikace, ve kterém jsou dostupné jen základní operace (CRUD). Jedná se vlastně o demonstraci nativní funkčnosti vlastního frameworku.

2.2.9

Grafika

Jelikož nejsem žádný grafik a nemůžu si dovolit zaplatit profesionálního grafika, který by mi navrhl design stránky, vybral jsem si jednu z mnoha webových šablon, které jsou zdarma k použití [23]. Jelikož u mé aplikace není potřeba žádných speciálních grafických efektů, ale naopak je důležitá přehlednost a srozumitelnost, omezil jsem výběr pouze na decentní návrhy. Další podmínkou byla automatická šířka návrhu podle aktuální velikost prohlížeče, nikoliv daná fixní šířka návrhu. Díky těmto omezením se výběr hodně ztenčil na opravdu pár vhodných návrhů. Nakonec se mi povedlo vybrat jeden vyhovující návrh. Bude tedy ještě potřeba na základě vzhledu stránky, vytvořit odpovídající vzhled obsahové části stránky (např. tabulky, navigace nebo nadpisy), ale to už by neměl být větší problém. Rozvržení (layout) stránky dodržuje nepsané standardy a obsahuje čtyři od sebe jasně oddělené části: • hlavička – obsahuje název aplikace, dostupné jazyky a odkaz na přihlášení / odhlášení, • menu – dává přihlášenému uživateli možnost pracovat s danými funkcemi, • obsahová část – zde se vykresluje veškerý obsah závislý na provedené akci, • patička – obsahuje copyright „výrobce“ a odkaz na stránku, kde byla stažena šablona. Ukázky aplikace jsou v příloze E.

26


Kapitola 3

Popis implementace 3.1

Použitý software

Níže uvádím seznam veškerého použitého softwaru, který jsem využil při tvorbě bakalářské práce. • WampServer 2.0 • Enterprise Architect 7.1 • MySQL Workbench 5.0.27 • NetBeans IDE 6.5 • PSPad 4.5.3 • Microsoft Office Word 2007 • Gimp 2.6.5 • WinEdt 5.6 • MiKTex 2.7 • Mozilla Firefox 3.0.10

3.2

Postup implementace

Implementace probíhala na základě agilních metodik (konkrétně extrémního programování) v jednotlivých iteracích. V rámci každé iterace bylo provedeno plánování včetně návrhu, samotná implementace a nakonec otestování již hotové části aplikace. Jedna iterace trvala přibližně týden, lépe řečeno pět pracovních dnů po osmi hodinách. Refaktorizaci kódu jsem prakticky nemusel vůbec provádět, protože před implementací jsem si zvolil jasně patřičné konvence a těch jsem se po celou dobu programování držel. Následuje popis jednotlivých iterací.

27

28

KAPITOLA 3. POPIS IMPLEMENTACE

První až druhá iterace Na úplném začátku bylo potřeba napsat základ aplikace, čili vlastní framework. Požadavky na framework nebyly kladeny nijak velké, byla jen nutnost poskytnout patřičnou podporu pro snadné napsání aplikace. Naopak robustnost by vedla k radikálnímu prodlužení časových odhadů a navíc by ji implementovaná práce ani nevyužila. Jak již bylo zmíněno v návrhu, framework by měl dodržovat MVC architekturu. Takže úkolem těchto iterací bylo naprogramovat model, řadič, pohled a jejich vzájemnou obsluhu. Testována byla funkčnost základních databázových operací, jako je vložení, úprava, mazání a čtení záznamů. Během testování bylo zjištěno několik malých chyb (např. nefungovala aktualizace textových záznamů, nahrazení cizího klíče názvem záznamu z cizí tabulky, . . . ), které byly okamžitě odstraněny. Většinou se jednalo o úpravu nebo přidání pár řádků kódu. Tato „dvojitá“ iterace byla zvolena kvůli náročnosti vytvoření frameworku a odladění chyb, které byly zjištěny během testování. Třetí iterace Jakmile byl hotov framework, musely se do aplikace zanést informace o modelech, které budou používány. Snaha byla, aby programátor musel vypisovat jen nejnutnější věci o daném modelu ve formě zadávání hodnot do proměnných, čímž opět došlo k úspoře času a kódu. V této iteraci byly vloženy do aplikace potřebné informace všech modelů. Testování bylo podobné jako v první iteraci, s tím že už se pracovalo s konkrétními daty nad konkrétními modely. Tentokrát byl zjištěn pouze jeden nedostatek. U modelů, které mezi sebou mají vztah N:M, se nesprávně aktualizovala jejich vztahová tabulka. Oprava byla jednoduchá, stačilo před úpravou vztahové tabulky vždy vymazat všechny existující relace mezi modely a teprve následně vložit nové. Čtvrtá iterace Modely sice už v aplikaci byly, ale nebyly mezi nimi žádné vazby. Tím je myšlena hlavně navigace, dostupné akce a vkládání formulářů v několika krocích napříč modely. Proto byly prozkoumány všechny modely a jejich možné vazby na modely jiné a následně byly tyto vazby zapsány (navigace, dostupné akce) nebo naprogramovány (formuláře). Při testování bylo kontrolováno, jestli se lze opravdu lehce dostat z jednoho modelu do modelů s ním spjatých. U formulářů byl otestován správný zápis do DB. Testy neobjevily žádné chyby. Pátá iterace V předposlední iteraci bylo zapotřebí dodělat funkce, které framework neposkytuje. Jedná se o generování čárových kódů a výplatních listů zaměstnanců, exporty dat s docházkou zaměstnanců a kontroly přítomnosti zaměstnanců na pracovišti. Generování dokumentů probíhalo do formátu PDF. Export musel být uložen ve formátu CSV, jelikož může nabývat velkých rozměrů jak do šířky, tak i výšky (v PDF by byla práce s daty nepřehledná). Po doprogramování kompletní funkčnosti aplikace přišlo na řadu testování nových funkcionalit. Byl nalezen jeden problém. Ve formuláři pro výběr období nebylo kontrolováno, zda

3.3. STRUKTURA APLIKACE

29

období od je menší než období do. Tato chyba sice nezpůsobila žádné problémy v aplikaci, ale je dobré ji mít podchycenou. Šestá iterace Poslední iterace nebyla iterací v tom pravém slova smyslu. Šlo jen o zapracování různých malých adekvátních připomínek k již hotové aplikaci, jako např. dynamické zobrazování dostupných akcí v terminálu na základě předchozí akce nebo při kontrole přítomnosti zaměstnance zobrazovat i aktuální přerušení pracovní doby. Jelikož byla pozměněna funkčnost některých akcí, bylo je potřeba znovu otestovat. Testování bylo úspěšné. Tato iterace netrvala ani týden, jak bylo zvoleno na začátku, ale „pouze“ dva dny. Tato doba stačila na dotáhnutí implementace do jejího úspěšného konce.

3.3 3.3.1

Struktura aplikace Hlavní obsluha

Srdcem neboli centrálou celé aplikace jsou dva soubory: .htaccess a index.php. .htaccess Je soubor, který slouží pro dodatečnou konfiguraci webového serveru (Apache). Tečkou začíná kvůli linuxovým serverům, a to z toho důvodu, aby byl skrytý. Dá se umístit do jakékoliv složky, přičemž se bude daná konfigurace vztahovat na aktuální složku a její podsložky. Jeho výhodou tedy je, že lze měnit konfiguraci webu bez zásahu do konfiguračního souboru Apache. Nejčastěji je tento soubor používán k přesměrování na jiné stránky (je potřeba mít na serveru povolený modul mod_rewrite) – to je i můj případ. Obsah souboru: 1. 2. 3. 4. 5. 6.

RewriteEngine On RewriteBase /dochazkovy-system RewriteCond %{REQUEST_URI} !\.[[:alnum:]]+$ RewriteRule ^(.+[^/])$ $1/ [R=301,QSA,L] RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)$ index.php?url=$1 [QSA,L]

Na prvním řádku se povolí přepisovací mechanismus. Dalším specifikujeme kořen aplikace vzhledem k serveru. Řádky 3 a 4 zajistí přidání lomítka na konec URL, pokud tam není. A poslední dva řádky jsou to hlavní pro aplikaci. Jedná se o jednoduché přesměrování na index.php s parametrem URL, do kterého se uloží cesta aplikace (např. pro URL http://localhost/dochazkovy-system/person/edit/1 je cesta person/edit/1). K přesměrování ale dojde pouze v případě, že se neodkazuje na soubor. Pokud se tomu tak stane, server se pokusí najít rovnou daný soubor.

30


Index.php Tento soubor se dostává ke slovu hned, jak je provedeno přesměrování z .htaccess. Na úplném začátku je potřeba provést nastartování relace (session), jelikož tato aplikace využívá jejich služeb. Poté se načtou soubory s třídami a potřebné konfigurační soubory pro běh systému, jako jsou např. připojení k DB nebo načtení statických textů. Načtení všech souborů s třídami je potřeba, protože by mělo být umožněno využít jakoukoliv třídu v aplikaci, aniž by se musel soubor s třídou explicitně načítat. Dále následuje pasáž, ve které dochází k rozdělení parametru URL podle lomítek, a to do maximálně čtyř částí. První částí je název modelu, druhou požadovaná akce, třetí identifikátor a poslední částí jsou parametry. První dvě jsou povinné, bez nich nelze vykonávat žádnou akci s modelem. Poté, co jsou známy všechny části URL, systém zjišťuje, zda se jedná o statickou stránku, dynamickou stránku anebo ani jedno. V případě statické stránky se načte patřičný PHP soubor a zobrazí se výsledná stránka pomocí Smarty. U dynamické stránky se vytvoří správný model, jenž je vstupním parametrem pro daný řadič spolu se všemi částmi URL. Po vykonání požadované funkcionality Smarty zobrazí stránku. Pokud pro požadavek neexistuje statická ani dynamická stránka, je zobrazena chyba 404 – stránka nenalezna. Na úplném konci životního cyklu aplikace je uzavřeno spojení s databází.

3.3.2

Model

Logika pro model je rozdělená do tří částí – hlavní databázový skript, databázové skripty pro konkrétní modely a skripty pro modely. Hlavní databázový skript (třída) je poskytován frameworkem. Jsou zde naimplementovány metody potřebné pro práci s DB. Do tohoto kódu by již nemělo být vůbec zasahováno, jelikož by došlo ke změně ve všech modelech aplikace, a to většinou nebývá žádoucí. V případě potřeby měnit funkčnost metod nebo přidávat metody vlastní, je žádoucí použít databázové skripty (třídy) pro konkrétní modely, které dědí veškerou funkčnost z hlavní databázové třídy. Zde lze existující metody přepsat nebo nové vytvořit. Nehrozí zde žádná kolize globálního měřítka (změny ve všech modelech). Skripty (třídy) pro modely dědí veškerou funkčnost z databázových tříd pro daný model. V těchto třídách se definují vlastnosti modelů. Především to je název a prefix databázové tabulky, dále seznam sloupců včetně způsobu validace ke kontrole při odeslání formuláře, relace k ostatním modelům a seznam textových sloupců. Detailní seznam všech možností s vysvětlením lze najít v příloze B.

3.3.3

Controller

Controller má velmi podobnou logiku jako model. Jen je zde rozdělen do dvou částí – hlavní controller skript a controller skripty pro konkrétní modely. Hlavní controller skript (třída) je poskytován frameworkem. Jdou zde naimplementovány metody potřebné pro „spolupráci“ pohledu a modelu. Jedná se o metody umožňující vkládání, úpravu, mazání a čtení záznamů z DB. Samozřejmě je zde i několik dalších pomocných metod,

3.3. STRUKTURA APLIKACE

31

jako např. validace formuláře, kontrola práv nebo logování událostí v aplikaci. Rovněž zde platí zásada, že do této třídy by se již nemělo zasahovat. Controller skripty (třídy) pro konkrétní modely fungují na úplně stejném principu jako databázové třídy pro konkrétní modely.

3.3.4

View

Je realizován pomocí šablonovacího systému Smarty. Realizace je poměrně jednoduchá. Controller předává potřebná data do view pomocí nastavení Smarty proměnných. Smarty pak pomocí vlastní syntaxe (především XHTML značek) generuje výsledný XHTML kód. Prohlížeč pak na základě tohoto kódu, aplikace CSS stylů a JavaScriptu vykreslí stránku. JavaScript je použit pro zobrazení kalendáře (využil jsem hotového řešení – JS Calendar [12]) u formulářových políček, kde je potřeba vložit datum. Slouží jako grafická pomůcka uživateli, který díky němu nemusí datum psát ručně, ale může si jej jednoduše navolit.

Obrázek 3.1: Ukázka kalendáře Služby JavaScriptu byly využity pro automatické odesílání formuláře, které se uplatňuje u identifikace zaměstnanců čárovým kódem. Tato funkce je mapovaná na formulářové políčko, kde se vyplňuje textová podoba čárového kód. Při každé změně v políčku se zkontroluje délka řetězce. Pokud je rovna třinácti (odpovídá formátu EAN-13), formulář se odešle. V opačném případě se nic neděje. JavaScript byl použit ještě jednou, a to pro zaškrtávání / odškrtávání zaškrtávacích políček u výběru práv pro uživatelský účet.

3.3.5

Moduly

Ve frameworku nebyl implementován žádný speciální systém, který by měl na starosti správu modulů, protože samotná práce s frameworkem (přidání nového modelu) je velmi podobná přidávání nového modulu. Každý model je totiž samostatná jednotka a používá své vlastní soubory. Nicméně, podpora pro moduly v aplikaci je. U nastavení informací o modelu lze totiž nastavit, zda se jedná o modul či ne. Aktivitu modulů se nastavuje v nastavení pro správce. Když je tedy model označen jako modul

32


a uživatel chce nad ním vykonat nějakou akci, řadič zkontroluje, jestli je modul v nastavení povolený. Na základě tohoto zjištění stránku zpřístupní nebo uživatele přesměruje na chybovou stránku 404 (stránka nenalezena).

3.3.6

Podpůrné skripty

Jedná se o pomocné skripty vesměs sloužící pro načtení úvodní konfigurace aplikace. Db-connect.php Naváže spojení s databází a zároveň nastaví používanou znakovou sadu. Původně bylo připojení k DB řešeno v konstruktoru hlavní databázové třídy. Jenže problém byl v tom, že při každém vytvoření modelu, se inicializovalo i připojení k DB, proto muselo dojít k přesunu do samostatného souboru. Ten následně vrací odkaz (referenci) na toto spojení pro použití v databázových příkazech. Db-disconnect.php Ukončí spojení s databází. Tento příkaz byl prováděn v destruktoru. Po přepsání připojení k DB došlo prakticky hned k odpojení od DB a aplikace končila chybou. Proto bylo nutné dát tento příkaz na úplný konec aplikace. Db-setting.php V tomto skriptu dochází pouze k načtení nastavení, které může měnit administrátor. Jde vlastně jen o přečtení všech záznamů daného modelu. Toto nastavení je pak přístupné pro celou aplikaci. Languages.php Zjišťuje, v jakém jazyce má být aplikace zobrazena a jaké jazyky jsou k dispozici. Na základě dostupných jazyků jsou v hlavičce stránky zobrazeny vlajky příslušných jazyků (států), které umožňují uživateli přepínat jazykovou mutaci aplikace. Určení aktuální jazykové mutace probíhá sekvenčně podle následujícího scénáře: • načtení jazyka podle GET parametru, • načtení jazyka uloženého v session, • načtení jazyka z informací od prohlížeče, • načtení jazyka podle administrátorského nastavení, • načtení jazyka podle nastavení pro programátory. Jakmile je úspěšný daný bod scénáře, k ostatním se už nepřistupuje. Zvolený jazyk je následně uložen do session. Logins.php Tento skript má na starosti zjistit, zda je uživatel přihlášen. Nejprve projde všechny uživatele za účelem odstranění příznaku přihlášení tam, kde vypršela doba přihlášení. Pokud se

3.4. SPECIÁLNÍ SKRIPTY

33

jeví daný uživatel pořád jako přihlášený, tak se mu jen prodlouží doba přihlášení. Static-texts.php Soubor načítá z databáze všechny statické texty potřebné pro aplikaci na základě jazyka uloženého v session. Menu.php Skript nejdříve najde všechny modely v aplikaci. Následně je postupně prochází a na základě dostupných akcí daného modelu vytváří systémové menu. Do něj jsou pak přidané jen ty akce, na které má momentálně přihlášený uživatel právo. Functions.php Jsou zde umístěny funkce, které se používají v celé aplikaci. Mezi ně patří např. vlastní zaokrouhlování, procházení adresářové struktury nebo zjištění IP adresy.

3.4

Speciální skripty

3.4.1

Skript pro zpracování docházky

Aby mohla být vypočtena mzda zaměstnance, je nejprve potřeba zpracovat jeho údaje z terminálu. Zpracování probíhá v rámci jednoho cyklu pro určené časové období. Skript se vždy snaží najít pár pro daný typ docházky (např. přestávka – začátek a přestávka – konec). V rámci tohoto páru spočítá spotřebovaný čas. Následuje tabulka vysvětlující počítání docházky. Pár příchod / odchod

V páru –

přerušení covní doby

příchod / odchod

pra-

lékař

příchod / odchod

lékař nemoc dovolená

– – –

Výpočet + odpracované hodiny (a zároveň přičtení do hodin pro víkendy, svátky a přesčasy, pokud tyto situace nastávají) - odpracované hodiny (a zároveň odečtení od hodin pro víkendy, svátky a přesčasy, pokud tyto situace nastávají) - odpracované hodiny (a zároveň odečtení od hodin pro víkendy, svátky a přesčasy, pokud tyto situace nastávají), + hodiny pro náhrady mzdy + hodiny pro náhrady mzdy + dny pro nemocenskou + dny pro dovolenou

Tabulka 3.1: Počítání docházky Spolu s údaji o docházce vrací tento skript i informaci o počtu pracovních dnů v daném období.

34

3.4.2


Výpočet mzdy

Při studiu této problematiky jsem použil program ÚČTO 2009 [20]. Mzda se počítá na základě informací z modelu pro mzdové podklady. Ze všeho nejdřív se musí zjistit průměr pro náhradu mzdy (částka za hodinu). Spočítá se tak, že se vezmou mzdové podklady z předešlých tří měsíců, z kterých je potřeba vytáhnout hrubou mzdu a odpracované hodiny. Průměr pro náhradu mzdy se dostane vydělením součtu hrubé mzdy za tři měsíce součtem odpracovaných hodin za tři měsíce. Pokud zaměstnanec neodpracoval ještě tři měsíce, počítá se tento průměr ze všech měsíců, které stihnul odpracovat. Jestliže ale neodpracoval ještě nic, tak se náhrady rovnají jeho hodinové mzdě (případně měsíční mzdě dělené odpracovanými hodinami). Hrubá mzda se skládá z několika položek. Především jde o samotnou mzdu. V případě, že má zaměstnanec přidělenou hodinovou mzdu, tak se pouze vynásobí odpracovanými hodinami. Pokud má měsíční mzdu a odpracoval méně hodin, než bylo k dispozici v daném měsíci (pracovní dny krát denní pracovní doba), tak se mu měsíční mzda úměrně zmenší vzhledem k odpracovaným hodinám. V opačném případě se měsíční mzda nemění. Dalšími položkami, které se připočítávají k hrubé mzdě, jsou příplatky za přesčasy, odpracované svátky a víkendy, náhrady mzdy (např. návštěva lékaře), placená dovolená a odměny. Pro výpočet placené dovolené a náhrad mezd se používá průměr pro náhradu mzdy. Daň z příjmů je 15 % ze superhrubé mzdy zaokrouhlené na celé stovky nahoru. Ta je součtem hrubé mzdy a odvodů zaměstnavatele na pojistném za zaměstnance. Pojistné činí 34 % z hrubé mzdy (9 % zdravotní pojištění, 25 % sociální pojištění). Čistá mzda se pak rovná hrubé mzdě, od které se odečte daň z příjmů a pojistné placené zaměstnancem. Toto pojistné je 11 % z hrubé mzdy (4,5 % zdravotní pojištění, 6,5% sociální pojištění). K čisté mzdě mohou být připočteny ještě nemocenské dávky. Nemocenská je proplácena zaměstnavatelem pouze během počátečních čtrnácti kalendářních dnů, přičemž se berou v úvahu jen pracovní dny bez prvních tří. Pro vypočtení hodinové sazby k vyplácení nemocenské se používá redukovaný průměrný výdělek, který se odvíjí od průměru pro náhrady mzdy (dále jako PPN). Postup pro získání tohoto výdělku je popsán v následující tabulce. PPN – od – 137,55 206,15 412,30

PPN – do 137,55 206,15 412,30 –

Redukovaný průměrný výdělek 90% z PPN 123,80 + 60% z (PPN - 137,55) 164,96 + 30% z (PPN - 206,15) 226,81

Tabulka 3.2: Výpočet nemocenských dávek

3.4.3

Generování čárového kódu

Aplikace používá čárový kód typu EAN-13, který je třináctimístný a obsahuje čtyři skupiny čísel:

3.5. NASTAVENÍ APLIKACE

35

• S – prefix státu – v Evropě přiděluje organizace European Article Numbering, • F – číslo firmy – v ČR přiděluje organizace GS1 CZECH REPUBLIC, • P – kód produktu – přiděluje daná firma sama, • K – kontrolní číslo, které je dopočítáno stanoveným algoritmem. EAN-13

S

S

S/F

F

F

F

F

F/P

F/P

P

P

P

K

Tabulka 3.3: Struktura čárového kódu EAN-13 O generování obrázku čárového kódu se stará knihovna Barcode Generator [1], která rovněž sama dopočítává kontrolní číslo. Po doplnění informací o zaměstnanci se vygeneruje PDF dokument s kartou zaměstnance, o což se postará knihovna DOMPDF [2], která dostane jako vstup HTML kód.

3.4.4

Export docházky zaměstnanců

Slouží jednak k přehledu o práci zaměstnanců, tak i pro možný import do jiných aplikací. Aby byly splněny obě podmínky, byl zvolen formát CSV oddělený středníky. Generování souboru ve formátu CSV nepotřebuje žádnou speciální knihovnu, jedná se totiž pouze o data oddělená středníkem a novým řádkem, což lze elegantně vyřešit pomocí příkazu, který postupně prochází pole. Výsledné soubory zobrazují na „ose x“ jednotlivé dny ze zvoleného období a na „ose y“ jména zaměstnanců. Samotný obsah je tvořen údaji z terminálu pro daný den a zaměstnance.

3.5 3.5.1

Nastavení aplikace Internet vs. intranet

Aplikace může být přístupná pouze ve vnitřní síti (intranet) nebo i mimo tuto síť (internet). Předpokládá se používání druhé varianty. Při omezení se pouze na intranet je potřeba provést potřebná nastavení. Existují dvě možnosti, přímo v konfiguraci serveru nebo přes soubor .htaccess. Server V konfiguračním souboru httpd.conf serveru (Apache) je potřeba přidat následující kód, který povoluje přístup k aplikaci v dané složce pouze počítačům s IP adresou z rozsahu 192.168.1.0/255.255.255.0. order deny,allow deny from all allow from 192.168.1.0/255.255.255.0

36


.htaccess Lze použít naprosto stejný kód, jen bez definice složky. Jelikož ta je provedena automaticky podle umístění souboru .htaccess.

3.5.2

Nastavení pro správce

Jedná se o soubor config.php, který je umístěn ve složce include. Zde se definují všechna důležitá nastavení pro aplikaci. K souboru by měl mít přístup pouze správce aplikace. Neodborná změna může vést k nefunkčnosti celé aplikace. Možnosti nastavení: • Databáze – název serveru a databáze, znaková sada a přístup (jméno a heslo). • Super admin – jméno a heslo pro přístup do systému jako super admin (může vykonávat všechny akce, vykonané akce se nelogují). • Ladění – slouží pro zobrazení databázových dotazů a obsahů objektů. • Moduly – povolování / zakazování modulů. • Zaškrtávání práv – slouží pro vygenerování odkazu, kterým se automaticky zaškrtnou zvolená zaškrtávací políčka u přidávání (úpravy) práv k uživatelskému účtu. • Čárový kód – nastavení formátu a vzhledu čárového kódu, prefixu státu a kódu firmy. • Cesty – URL aplikace, cesta k řadičům a modelům. • Jazyk – definice výchozího jazyka aplikace. • Datum a čas – nastavení formátů data a času pro kalendář, formuláře a regulární výrazy. • IP adresa terminálu – na této IP adrese bude terminál přístupný bez nutnosti přihlásit se do aplikace. • Formulářové políčka – mapování typů sloupců z DB na typy formulářových políček. • Smarty – nastavení cest potřebných pro běh Smarty.

Kapitola 4

Testování Testování neodmyslitelně patří k vývoji jakéhokoliv softwaru. Cílem je objevit a opravit co nejvíce chyb. Testováním nelze zaručit absolutní bezchybnost aplikace, jelikož není reálné nasimulovat všechny možné vstupy, výstupy, možnosti a situace. Přesto lze kvalitním testováním objevit většinu chyb, na které by mohl uživatel při běžné práci narazit, a zároveň přijít na různá uživatelská vylepšení, což významným způsobem zvyšuje kvalitu produktu. Svou aplikaci jsem prověřil dvěma druhy testování: • testy funkčnosti, • testy uživatelského rozhraní.

4.1

Testování funkčnosti

Testování funkčnosti neboli funkcionální testování zjišťuje, zda naimplementovaná funkcionalita odpovídá funkčním požadavkům na aplikaci. Samozřejmě ověřuje i správnou činnost (odpovídající výstup na základě určitého vstupu) dílčích částí. Testování neprobíhalo jen po vytvoření aplikace, ale již v průběhu vývoje, což koresponduje s použitím techniky extrémního programování. Pro testování správného a požadovaného chování aplikace jsem použil dvou nástrojů: • SimpleTest [22], • Selenium IDE [21].

4.1.1

Jednotkové testy

Jednotkové testy (unit testy) slouží k otestování funkčnosti části (jednotky) zdrojového kódu. Za jednotku se považuje samostatně testovatelná část kódu. Typicky to bývá funkce či procedura v případě procedurálního programování nebo metoda v případě programování orientovaného objektově. Unit testy se tedy hodí pro základní otestování správné funkčnosti daného kódu, s tím že mu dáme nějaký vstup a na jeho základě očekáváme patřičný výstup. Pokud jej dostaneme,

37

38

KAPITOLA 4. TESTOVÁNÍ

je vše v pořádku, jinak testovaný kód nedělá to, co se po něm požaduje a je potřeba jej opravit. Výhodou těchto testů je jejich znovupoužitelnost. Požadovaná funkčnost části kódu se v čase totiž nemění (mohou však nastat případy, kdy je potřeba změny), kdežto samotný kód ano. Toho lze využít k odhalení regresivních chyb, které mohou vzniknout na základě změny kódu. Proto je vhodné testy uchovávat a na konci každé iterace je spouštět. Pro psaní a provádění jednotkových testů jsem využil služeb frameworku SimpleTest. Jeho použití je opravdu snadné a navíc umí vše, co jsem potřeboval. Stažený balíček stačilo rozbalit a umístit do zvoleného adresáře aplikace. Poté bylo potřeba napsat už jen jednotlivé testy a spustit je v prohlížeči (respektive soubor, ve kterém jsou uloženy). SimpleTest následně vrátí výsledek testů. Ukázka jednoduchého otestování funkce pro zaokrouhlování: assertEqual(1.75, ownRound(1.66,"quarter")); } } ... ?> Výstup v případě úspěchu (vrací funkce ownRound(1.66,"quarter") hodnotu 1.75?): Test functions: OK Test cases run: 1/1, Passes: 1, Failures: 0, Exceptions: 0 Výstup v případě neúspěchu (vrací funkce ownRound(1.6,"quarter") hodnotu 1.75?): Test functions: 1) Equal expectation fails because [Float: 1.75] differs from [Float: 1.5] by 0.25 at [D:\www\dochazkovy-system\tester.php line 25] in testRounding in FunctionsTests FAILURES!!! Test cases run: 1/1, Passes: 0, Failures: 1, Exceptions: 0

4.1. TESTOVÁNÍ FUNKČNOSTI

39

Jednotkové testy mi pomohly hlavně při odhalování regresivních chyb, jelikož jsem kód měnil poměrně často (především kódy pro framework). Kdyby nedošlo k nalezení těchto chyb, bylo by potřeba dlouho procházet kód a hledat vzniklý problém. To by vedlo k zbytečnému prodloužení času potřebného pro vývoj aplikace.

4.1.2

Testy akcí v prohlížeči

Je potřeba prozkoumat, jak se daná aplikace doopravdy chová v prohlížeči. Proto je ideální provádět testy přímo v prohlížečích, pro které je aplikace určena, jelikož zde vstupuje do hry i JavaScript, potažmo AJAX. Já jsem se zaměřil především na kontrolu správné funkčnosti formulářů. Pro testování jsem použil program Selenium IDE, který lze stáhnout jako rozšíření do internetového prohlížeče Mozilla Firefox. Práce s ním je velmi jednoduchá. Funguje na principu provádění určité posloupnosti akcí. Navíc není potřeba tuto posloupnost psát, stačí si ji nahrát. K tomu je potřeba zapnout nahrávání a na testované stránce provádět požadované akce (např. kliknutí nebo psaní textu). Do sledu akcí je možné vkládat různé kontroly, které právě slouží k otestování správné funkčnosti chování aplikace. Níže je uveden obrázek, který demonstruje použití testovacího prostředí. Jedná se o simulaci neúspěšného přihlášení do systému, kdy se očekává vypsání patřičné chybové zprávy. Jak lze vidět z logu, vše proběhlo v pořádku.

Obrázek 4.1: Ukázka testu v programu Selenium IDE

40


4.2

Testování uživatelského rozhraní

Správná funkčnost aplikace není zdaleka vše. Proto, aby byla aplikace použitelná, musí mít také dobře navržené své uživatelské rozhraní. Profil uživatelů Uživatele, kteří budou používat aplikaci, lze rozdělit na dvě skupiny: laici v oblasti počítačů (základní zkušenosti s počítačem – zapnutí, vypnutí, jednoduché používání internetu) a uživatele, kteří mají s počítačem, potažmo internetem, již nějaké zkušenosti. Vymezovat další rysy je bezvýznamné, jelikož aplikaci může používat opravdu celá škála typově odlišných lidí.

4.2.1

Kognitivní průchod

Nejprve jsem provedl kognitivní průchod, abych eliminoval nejviditelnější chyby a neplýtval zbytečně energií uživatelů, kteří budou provádět test použitelnosti. Kognitivní průchod je vlastně to samé jako test použitelnosti, jen jej nedělají uživatelé, ale samotný návrhář. Výhodou je, že nejsou potřeba žádné testovací osoby, což vede k úspoře času a peněz. Nevýhodou naopak je, že se návrhář musí vžít do role uživatele (musí vycházet z jeho profilu). Na základě kognitivního průchodu vzniknou návrhy na opravu případných chyb, které je potřeba opravit. Po opravě se znovu provede kognitivní průchod. Během testu je potřeba klást si tyto otázky: • Vím, kde se právě nacházím? • Mám k dispozici potřebnou akci? • Je to správná akce? • Chápu zpětnou vazbu aplikace? Zaměření testu: • jasně rozdělená struktura stránky, • velikost písma a jeho odsazení, • dostupné akce v různých situacích, • přehlednost výpisu dat, • jasné zobrazování chybových a informačních zpráv, • korektnost zobrazovaných dat a výsledků.

4.2. TESTOVÁNÍ UŽIVATELSKÉHO ROZHRANÍ

41

Výsledek a důsledky provedeného testu Velikost textu a odsazení se musela radikálně zmenšit, jelikož byla opravdu moc velká a na stránku se proto vešlo málo informací. Bylo potřeba přidat navigační lištu, ve které budou dostupné relevantní akce vzhledem k aktuální stránce. Při procházení dat v tabulce se dalo poměrně lehce ztratit. Proto přibylo zvýrazňování řádků tabulky při najetí myši na ně. Chybové a informační zprávy se musely barevně odlišit, aby uživatel už intuitivně podle barvy poznal, zda je pouze informován nebo nastal nějaký problém. Po opravě vzniklých problémů, byl proveden znovu kognitivní průchod s naprosto stejným zaměřením. Žádné nové chyby už nebyly zjištěny.

4.2.2

Test použitelnosti

K testování bylo přizváno pět uživatelů. Dva byli úplní laici a tři naopak poměrně zkušení. Zvykem je použití dotazníků před zahájením testu i po jeho skončení. Já jsem použil jen dotazník po dokončení testu, jelikož všechny uživatele dobře znám, tudíž by zjišťování jejich základních informací byla pouze zbytečná práce navíc. Dotazníky slouží k získání přehledu o daném uživateli a zároveň taky jako důležitý faktor pro vyhodnocení testu. Například když víme, že uživatel v životě „nesáhl“ na počítač, tak se nebudeme příliš pozastavovat nad délkou vykonávání přiděleného úkolu. Naopak u člověka, který má s počítačem bohaté zkušenosti, by to bylo velmi zarážející a poukazovalo by to na nějaký problém. Příprava testu Příprava testu byla poměrně jednoduchá a nenáročná. Uživatelům jsem rozdal vytištěný uživatelský manuál (příloha G), který měli za úkol nastudovat a ptát se na případné nejasnosti. Poté následovalo vysvětlení, co se po nich bude chtít: • Otevření internetové stránky s aplikací a následné přihlášení. • Kontrola osobních údajů. • Změna hesla k uživatelskému účtu. • Zkontrolování vlastní docházky. • Označení příchodu do práce na terminálu za použití karty s čárovým kódem. • Ruční přidání docházky pro zaměstnance. • Přidání nového typu přerušení pracovní doby. • Přidání nového zaměstnance do firmy. • Zjistit (ne)přítomnost zaměstnance na pracovišti v určený den. • Export přehledu práce všech zaměstnanců za dané období. • Vygenerování karty s čárovým kódem pro zaměstnance.

42


• Změnit počet odpracovaných hodin zaměstnance s následným přepočítáním mzdového podkladu. • Vygenerování výplatního listu zaměstnance. • Změnit způsob zaokrouhlování hodin a dnů ve mzdových podkladech. Průběh testu Každého uživatele jsem posadil na místo, kde byl připraven zapnutý počítač s operačním systémem MS Windows XP. Uživatelé měli před sebou papír s úkoly, které měli vyřešit. Já jsem byl pouze v roli pozorovatele. Byl jsem ale připraven pomoci v případě, že by někdo výrazně tápal a už nevěděl kudy kam. Tahle situace však nenastala, což může být prvním znakem přehledného uživatelského manuálu a dobře navrženého uživatelského rozhraní. Po testu každý účastník ještě vyplnil krátký závěrečný dotazník. Závěrečný dotazník Máte zkušenosti s nějakými webovými systémy (např. emailová schránka, chat)? • U1 – ano, email používám na seznamu. • U2 – chodím na internet hledat jen auta. • U3 – samozřejmě. • U4 – ano. • U5 – ano. Uvítal/a byste tento systém u vás v práci? • U1 – je mi to celkem jedno. • U2 – ano, líbí se mi ten přehled o mé práci. • U3 – nepracuji. • U4 – zřejmě ano. • U5 – ano. Byl pro vás text (písmo) dostatečně čitelný? • U1 – ano, určitě, jen písmo v menu by mohlo být menší. • U2 – text se mi v tabulkách četl trochu hůře. • U3 – bez problému, jen by to možná chtělo větší odsazení textu v seznamech. • U4 – ano. • U5 – kontrast s pozadím se mi nezdá dostatečný.

4.2. TESTOVÁNÍ UŽIVATELSKÉHO ROZHRANÍ

43

Byla pro vás práce se systémem příjemná a jednoduchá? • U1 – líbilo se mi, jak je všechno jednoduché. • U2 – díky manuálu se to celkem dalo. • U3 – ano. • U4 – až moc jednoduchá. • U5 – příjemná nevím, ale jednoduchá každopádně. Zlepšili byste něco, případně co? • U1 – nic mě nenapadá. • U2 – zvětšení buněk v terminálu. • U3 – hezčí grafiku. • U4 – ne. • U5 – asi nic. Výsledek a důsledky provedeného testu Jak se dalo předpokládat, čas potřebný pro vykonání jednotlivých úkolů byl u laiků zhruba třikrát větší než u zkušených uživatelů. Bylo to způsobené tím, že laici se nad každou akcí dlouho rozmýšleli. Z rozhovoru s nimi vyplynulo, že měli strach, aby něco nepokazili. Samotný test uživatelského rozhraní dopadl velmi dobře. Bylo potřeba udělat jen pár kosmetických úprav: • lehké zvětšení písma a odsazení v tabulkách, • zesvětlení pozadí a ztmavení písma kvůli většímu kontrastu, • zvětšení buněk v terminálu. To, že dopadl test celkem slušně, přisuzuji hlavně dobře zvolenému jednoduchému rozložení stránky. Jistý faktor v tom hrál i kognitivní průchod, díky kterému došlo k odstranění několika chyb, které by jistě překážely také uživatelům.

44


Závěr Cílem práce bylo navrhnout, vytvořit a důkladně otestovat webový docházkový systém. Tento systém je primárně určen jen pro menší podniky. Je postaven na frameworku, který jsem vytvořil nakonec sám namísto použití již hotového. Framework, dodržující MVC architekturu, umožňuje snadné přidávání nových modulů. Při vývoji aplikace jsem vycházel především z provedené rešerše, kde jsem zjistil, co by takový systém měl umět a kde jsou rezervy zkoumaných systémů. Hlavním inspiračním zdrojem byl docházkový systém od firmy ANeT. Když jsem porovnával svou výslednou aplikaci s aplikací od firmy ANeT v konfiguraci „Personal“ nebo „Basic“ (zaměření na malé a střední firmy), tak jsem došel k závěru, že se mi podařilo vytvořit konkurence schopný produkt. V určitých směrech (např. generování výplatních listů nebo vícejazyčný systém) má práce dokonce převyšuje konkurenci, v jiných zase trochu zaostává (především se jedná o detailní přehledy o práci zaměstnanců). Přínos práce byl pro mě celkem značný. Ověřil jsem si, že jsem opravdu schopný vyvinout plně funkční objektově orientovanou aplikaci. Poprvé jsem svědomitě postupoval podle pravidel pro vývoj softwaru od návrhu (úvodní studie) přes implementaci až po závěrečné testování. Využil jsem znalostí získaných během mého studia a co je důležitější, dokázal jsem je uplatnit v praxi. Pročetl jsem desítky stránek literatury, abych získal patřičné vědomosti vedoucí k úspěšnému dokončení práce. Aplikace má velký potenciál z hlediska její rozšiřitelnosti. Současná verze je určena pro menší firmy, čili nemá žádné extra funkce navíc. Systém je tedy možné rozšířit např. o různorodé přehledy a statistiky, interaktivní grafy pomocí technologie AJAX či Flash, notifikace (okamžitá reakce na událost v aplikaci) nebo eskalace (časově řízená reakce na událost v aplikaci). Samotný framework má pak menší mezeru v optimalizaci databázových příkazů, díky níž by mohlo dojít k zrychlení řádově v setinách až desetinách sekundy, u složitých dotazů by se mohlo jednat i o vteřiny. Celkový čas potřebný pro vytvoření bakalářské práce byl zhruba 330 hodin, což celkem odpovídá číslu, které bylo odhadnuto před samotnou implementací systému. Na základě výše zmíněného mohu říct, že vytyčené cíle práce se mi podařilo naplnit.

45

46

ZÁVĚR

Literatura [1] Barcode Generator. http://www.barcodephp.com/, stav z 31. 5. 2009. [2] DOMPDF. http://www.digitaljunkies.ca/dompdf/, stav z 31. 5. 2009. [3] Informace o AJAXu. http://cs.wikipedia.org/wiki/Asynchronous_JavaScript_and_XML, 31. 5. 2009.

stav

[4] Informace o architektuře MVC. http://cs.wikipedia.org/wiki/Model-view-controller, stav z 31. 5. 2009. [5] Informace o ASP.NET. http://cs.wikipedia.org/wiki/ASP.NET, stav z 31. 5. 2009. [6] Informace o CSS. http://cs.wikipedia.org/wiki/Cascading_Style_Sheets, stav z 31. 5. 2009. [7] Informace o Java EE. http://cs.wikipedia.org/wiki/J2EE, stav z 31. 5. 2009. [8] Informace o JavaScriptu. http://cs.wikipedia.org/wiki/JavaScript, stav z 31. 5. 2009. [9] Informace o Master Pages. http://interval.cz/clanky/master-pages-v-asp-net-2-0/, stav z 31. 5. 2009. [10] Informace o PHP. http://cs.wikipedia.org/wiki/PHP, stav z 31. 5. 2009. [11] Informace o XHTML. http://cs.wikipedia.org/wiki/XHTML, stav z 31. 5. 2009. [12] JavaScript Calendar. http://www.dynarch.com/projects/calendar/old/, stav z 31. 5. 2009. [13] Manuál MySQL. http://www.mysql.com/, stav z 31. 5. 2009.

47

z

48

LITERATURA

[14] Manuál PHP. http://www.php.net/, stav z 31. 5. 2009. [15] Manuál Smarty. http://www.smarty.net/, stav z 31. 5. 2009. [16] Oficiální stránky firmy ANeT-Advanced Network Technology, s.r.o. http://www.anet.info/, stav z 31. 5. 2009. [17] Oficiální stránky firmy Ing.Vladimír Zavřel Z-WARE. http://www.z-ware.cz/, stav z 31. 5. 2009. [18] Oficiální stránky firmy IReSoft, s.r.o. http://www.iresoft.cz/, stav z 31. 5. 2009. [19] Oficiální stránky firmy Mersite s.r.o. http://www.mersite.cz/, stav z 31. 5. 2009. [20] Oficiální stránky programu ÚČTO 2009. http://www.ucto2000.cz/, stav z 31. 5. 2009. [21] Selenium IDE. http://seleniumhq.org/projects/ide/, stav z 31. 5. 2009. [22] SimpleTest. http://www.simpletest.org/, stav z 31. 5. 2009. [23] Webové šablony zdarma k použití. http://www.freecsstemplates.org/, stav z 31. 5. 2009. [24] J. R. Groff and P. N.Weinberg. SQL kompletní průvodce. CP Books, 1th edition, 2005. [25] A. Gutmans, S. S. Bakken, and D. Rethans. Mistrovství v PHP 5. CP Books, 1th edition, 2005. [26] S. Holzner. JavaScript profesionálně. Mobil Media, 1th edition, 2003. [27] V. Kadlec. Agilní programování. Computer Press, 1th edition, 2004. [28] H. Kanisová and M. Müller. UML srozumitelně. Computer Press, 1th edition, 2004.

Příloha A

Seznam použitých zkratek .NET dot network AJAX Asynchronous JavaScript and XML ASP Active Server Pages CLR Common Language Runtime CRUD Create, read, update and delete (vytvořit, číst, upravit a smazat) CSS Cascading Style Sheets (tabulky kaskádových stylů) CSV Comma-separated values (hodnoty oddělené čárkami) DB Database (databáze) DOC Microsoft Word file (dokument používaný programem Microsoft Word) DOM Document Object Model (objektový model dokumentu) EAN-13 European Article Number EBML Extensible Binary Meta Language (rozšiřitelný binární meta jazyk) HTML HyperText Markup Language (značkovací jazyk pro hypertext) IDE Integrated Development Environment (vývojové prostředí) IP Internet Protocol (internetový protokol) Java EE Java Platform, Enterprise Edition JSON JavaScript Object Notation (JavaScriptový objektový zápis) JSP JavaServer Pages JSTL JavaServer Pages Standard Tag Library MB Megabyte (megabajt)

49

50

PŘÍLOHA A. SEZNAM POUŽITÝCH ZKRATEK

MVC Model-view-controller (Model-pohled-řadič) PDF Portable Document Format (přenosný formát dokumentů) PHP Hypertext Preprocessor (hypertextový preprocesor) UML Unified Modeling Language (unifikovaný modelovací jazyk) URL Uniform Resource Locator (jednotný lokátor zdrojů) XHTML eXtensible Hypertext Markup Language (rozšiřitelný hypertextový značkovací jazyk) XLS Microsoft Excel spreadsheet file (dokument používaný programem Microsoft Excel) XML eXtensible Markup Language (rozšiřitelný značkovací jazyk)

Příloha B

Nastavitelné vlastnosti modelu Vlastnost databaseLink modelName tablePrefix tableName primaryKey texts valid recordName template table relations relationModels relation1to1 relation1toN relationNtoM private module allowLog ownRecords actionsInMenu

Význam reference na spojení s databází název modelu prefix jména databázové tabulky jméno databázové tabulky bez prefixu primární klíč databázové tabulky názvy textových polí, které používá databázová tabulka názvy kontrolovaných polí databázové tabulky spolu s typem validace název pole, z něhož se bude brát hodnota pro indetifikaci záznamu název šablonovacího souboru bez přípony celý název databázové tabulky (tablePrefix+tableName) typy databázových relací reference na modely, na které má vazbu databázová tabulka názvy modelů, se kterými je databázová tabulka v relaci 1:1 názvy modelů, se kterými je databázová tabulka v relaci 1:N názvy modelů, se kterými je databázová tabulka v relaci N:M říká, zda je potřeba přihlásit se pro práci s modelem říká, zda je model modul říká, zda se mají akce v modelu zaznamenávat do logu říká, zda uživatelé mohou pracovat jen se svými daty názvy akcí, které se objeví v menu aplikace Tabulka B.1: Vlastnosti modelu

51

52

PŘÍLOHA B. NASTAVITELNÉ VLASTNOSTI MODELU

Příloha C

Datový model

Obrázek C.1: Datový model systému – část 1

53

54

PŘÍLOHA C. DATOVÝ MODEL

Obrázek C.2: Datový model systému – část 2

Příloha D

UML Při studiu této problematiky jsem použil knihu UML srozumitelně [28].

D.1 D.1.1

Případy užití Diagram

55

56

PŘÍLOHA D. UML

Obrázek D.1: Případy užití – interakce se systémem

D.1. PŘÍPADY UŽITÍ

D.1.2

57

Scénáře

Identifikovat zaměstnance 1. Případ užití začíná, když je zaměstnanec u terminálu vyzván k identifikaci. 2. Zaměstnanec se musí identifikovat (např. pomocí čárového kódu). Vybrat typ docházky 1. Případ užití začíná, když je zaměstnanec u terminálu vyzván k výběru typu docházky. 2. Systém automaticky doplní příznak začátek/konec k typům docházky podle předchozí akce. 3. Zaměstnanec vybere požadovaný typ docházky (např. přestávka). Zaznamenat docházku 1. Případ užití začíná, když zaměstnanec pracuje s terminálem. 2. INCLUDE (Identifikovat zaměstnance). 3. INCLUDE (Vybrat typ docházky). 4. Systém zaznamená docházku zaměstnance. 5. Systém „odhlásí“ zaměstnance. Přihlásit se do systému 1. Případ užití začíná, když se uživatel rozhodne přihlásit do systému. 2. Uživatel vyplní přihlašovací jméno a heslo. 3. Pokud jsou údaje správné, systém uživatele přihlásí. Odhlásit se ze systému 1. Případ užití začíná, když se uživatel rozhodne odhlásit ze systému. 2. Uživatel klikne na odkaz „odhlásit se“ 3. Systém bezpečně odhlásí uživatele. Odhlásit automaticky 1. Případ užití začíná, když vyprší doba přihlášení uživatele. 2. Systém automaticky odhlásí daného uživatele.

58

PŘÍLOHA D. UML

Validovat formulář 1. Případ užití začíná, když dojde k odeslání formuláře. 2. Systém zkontroluje formulář. 3. Pokud nebyla validace úspěšná, uživateli se zobrazí vyplněný formulář znovu s popisem validačních chyb. Zkontrolovat práva 1. Případ užití začíná před každou akcí přihlášeného uživatele v systému. 2. Systém zjistí, zda má přihlášený uživatel právo vykonávat danou akci. 3. Pokud uživatel nemá patřičná práva, je na to upozorněn a akce, která měla být vykonána, se neprovede. Číst záznam {KonkrétníModel} 1. Případ užití začíná, když chce uživatel číst záznam(y). 2. Uživatel si vybere data ke čtení. 3. INCLUDE (Zkontrolovat práva). 4. Systém načte patřičná data z DB. Mazat záznam {KonkrétníModel} 1. Případ užití začíná, když chce uživatel smazat záznam. 2. INCLUDE (Zkontrolovat práva). 3. Uživatel potvrdí smazání nebo jej zruší (tím končí i případ užití). 4. Systém vymaže daný záznam z DB. Přidat záznam {KonkrétníModel} 1. Případ užití začíná, když chce uživatel přidat záznam. 2. INCLUDE (Zkontrolovat práva). 3. Uživatel vyplní formulář. 4. INCLUDE (Validovat formulář). 5. Systém vloží nový záznam do DB. Upravovat záznam {KonkrétníModel} 1. Případ užití začíná, když chce uživatel upravit záznam.

D.1. PŘÍPADY UŽITÍ

59

2. INCLUDE (Zkontrolovat práva). 3. Systém načte patřičná data z DB pro vyplnění formuláře. 4. Uživatel upraví formulář. 5. INCLUDE (Validovat formulář). 6. Systém upraví daný záznam v DB. Zvolit období 1. Případ užití začíná, když musí uživatel vybrat období. 2. Uživatel vybere období od. 3. Uživatel vybere období do. Zvolit datum 1. Případ užití začíná, když musí uživatel vybrat datum. 2. Uživatel vybere datum. Vybrat zaměstnance v oddělení 1. Případ užití začíná, když chce uživatel pracovat s daty a tyto data se týkají zaměstnanců. 2. Uživatel zvolí oddělení. 3. Systém automaticky vybere zaměstnance z daného oddělení. Zvolit zaměstnance 1. Případ užití začíná, když chce uživatel pracovat s daty a tyto data se týkají zaměstnanců. 2. EXTEND (Vybrat zaměstnance v oddělení). 3. Uživatel vybere zaměstnance. Exportovat data 1. Případ užití začíná, když chce uživatel exportovat data o docházce zaměstnanců. 2. INCLUDE (Zkontrolovat práva). 3. INCLUDE (Zvolit zaměstnance). 4. INCLUDE (Zvolit období). 5. INCLUDE (Číst záznam).

60

PŘÍLOHA D. UML

6. Systém vyexportuje dané data za dané období. Zkontrolovat přítomnost 1. Případ užití začíná, když chce uživatel zjistit přítomnost zaměstnance(ů) na pracovišti. 2. INCLUDE (Zkontrolovat práva). 3. INCLUDE (Zvolit zaměstnance). 4. INCLUDE (Zvolit datum). 5. INCLUDE (Číst záznam). 6. Systém vypíše zprávu o (ne)přítomnosti zaměstnance(ů). Generovat výplatní list 1. Případ užití začíná, když chce uživatel vygenerovat výplatní list pro zaměstnance. 2. INCLUDE (Zkontrolovat práva). 3. INCLUDE (Číst záznam). 4. Systém vygeneruje výplatní list pro zaměstnance. Generovat čárový kód 1. Případ užití začíná, když chce uživatel vygenerovat čárový kód pro zaměstnance. 2. INCLUDE (Zkontrolovat práva). 3. INCLUDE (Číst záznam). 4. Systém vygeneruje čárový kód pro zaměstnance.

D.2

Sekvenční diagramy

D.2. SEKVENČNÍ DIAGRAMY

Obrázek D.2: Sekvenční diagram – životní cyklus aplikace

61

62

PŘÍLOHA D. UML

Obrázek D.3: Sekvenční diagram – načítání relací

Obrázek D.4: Sekvenční diagram – výběr akce


Obrázek D.5: Sekvenční diagram – načtení seznamu záznamů

63

64

PŘÍLOHA D. UML

Obrázek D.6: Sekvenční diagram – načtení detailu záznamu


Obrázek D.7: Sekvenční diagram – smazání záznamu

65

66

PŘÍLOHA D. UML

Obrázek D.8: Sekvenční diagram – práce s formulářem


Obrázek D.9: Sekvenční diagram – načtení dat pro formulář

67

68

PŘÍLOHA D. UML

Příloha E

Ukázky aplikace

Obrázek E.1: Ukázka aplikace – přihlášení

Obrázek E.2: Ukázka aplikace – karta zaměstnance

69

70

PŘÍLOHA E. UKÁZKY APLIKACE

Obrázek E.3: Ukázka aplikace – terminál

Obrázek E.4: Ukázka aplikace – formulář

71

Obrázek E.5: Ukázka aplikace – seznam záznamů

Obrázek E.6: Ukázka aplikace – detail záznamu

72

PŘÍLOHA E. UKÁZKY APLIKACE

Obrázek E.7: Ukázka aplikace – výplatní list zaměstnance

Příloha F

Instalační manuál Pro úspěšné dokončení instalace je potřeba mít server Apache alespoň ve verzi 2, PHP ve verzi 5 a MySQL s podporou úložiště InnoDB. Apache musí mít povolený modul mod_rewrite.Toho docílíte odkomentovaním řádku LoadModule rewrite_module modules/mod_rewrite.so v konfiguračním souboru serveru httpd.conf. 1. Zkopírujte obsah složky dochazkovy-system do požadovaného adresáře. 2. Vytvořte databází pomocí skriptu create.sql. 3. Nastavte správné údaje pro databázi v souboru include/config.php na řádcích 7 – 11. 4. Nastavte URL, na které poběží aplikace, v souboru include/config.php na řádku 91. 5. Nastavte relativní cestu (vždy začínejte znakem /) vzhledem ke kořenu serveru v souboru .htaccess na řádku 2. 6. Adresáři view/images/barcode/ nastavte práva pro zápis. 7. Všem složkám v adresáři include/Smarty-2.6.22/files/ nastavte práva pro zápis. 8. Pomocí údajů pro super admina (souboru include/config.php, řádek 23 a 24) se přihlašte do aplikace a v ní vytvořte administrátora (nejspíše to bude sám zaměstnavatel). 9. Pomocí Cronu nastavte automatické spouštení pro URL www.vasserver.cz/wages-employees-ledger/ledger-cron/ na každý druhý den v měsíci.

73

74

PŘÍLOHA F. INSTALAČNÍ MANUÁL

Příloha G

Uživatelský manuál G.1

Pro zaměstnance

Vzhled aplikace

Obrázek G.1: Uživatelský manuál – vzhled aplikace

Změna jazyka Jazyk aplikace si můžete změnit kliknutím na příslušnou vlajku v levém horním menu (G.1, část 1). Přihlášení do aplikace Nejprve klikněte na odkaz „přihlásit se“ v pravém horním rohu (G.1, část 2). V zobrazovací části (G.1, část 4) se objeví formulář, kde je potřeba vyplnit uživatelské jméno a heslo, které vám přidělil administrátor aplikace. Po vyplnění všech údajů odešlete formulář stisknutím tlačítka „přihlásit se“. V případě neúspěšného přihlášení se vám zobrazí zpráva, která obsahuje popis vzniklé chyby.

75

76

PŘÍLOHA G. UŽIVATELSKÝ MANUÁL

Obrázek G.2: Uživatelský manuál – přihlášení do aplikace

Odhlášení z aplikace V pravém horním rohu (G.1, část 2) klikněte na odkaz „odhlásit se“. Systém vás následně bezpečně odhlásí. Práce se systémem Po přihlášení vidíte v levé části menu (G.1, část 3), kde jsou dostupné akce, které můžete provádět v systému. Základní údaje Zobrazí detail vašich základních údajů. Nemůžete je měnit, v případě změny, kontaktujte prosím svého nadřízeného a ten zajistí příslušné změny. Proměnné údaje Zobrazí seznam všech vašich osobních údajů, které se mohou v čase měnit a používají se ve mzdových podkladech. Uživatelský účet Zobrazí detail vašeho uživatelského účtu, přičemž máte možnost si změnit jak přihlašovací jméno pomocí odkazu „upravit“ v navigační liště, tak i heslo pomocí odkazu „změnit heslo“ v navigační liště. V obou dvou případech se zobrazí jednoduchý formulář, kde vyplníte pouze jeden údaj a následně stisknete tlačítko „uložit“ pro zanesení změny do systému. Docházka Zobrazí seznam veškeré vaší docházky. Mzdové podklady Zobrazí seznam všech mzdových podkladů, které vám firma vystavila. Pokud se chcete dozvědět více o vašem mzdovém podkladu, stačí v seznamu na příslušném řádku kliknout na odkaz „detail“. Poté se zobrazí podrobný výpis všech účetních položek potřebných pro výpočet vaší mzdy.

G.1. PRO ZAMĚSTNANCE

77

Čárový kód Zobrazí textovou podobu vašeho čárového kódu. K této akci se dostanete přes navigační lištu v základních údajích pomocí kliknutí na odkaz „čárový kód“. Mzda a odměny Zobrazí detail o vaší mzdě a odměnách. K této akci se dostanete přes navigační lištu v základních údajích pomocí kliknutí na odkaz „mzda a odměny“. Navigační lišta Zobrazuje se vždy pro každou stránku v systému, pokud existují akce, které mají logickou návaznost na aktuální činnost, a tudíž mohou být v liště zobrazeny. Poslouží vám tedy hlavně k rychlejší práci s aplikací.

Obrázek G.3: Uživatelský manuál – navigační lišta

Filtrování a řazení v seznamech Pro příjemnější a pohodlnější práci v seznamech můžete využít jak filtrů, tak i řazení. Filtr je zobrazen nad každým sloupcem tabulky a umožňuje ponechat v tabulce jen ty záznamy, u kterých hodnota sloupců odpovídá nastaveným filtrům. Filtrování se aplikuje, pokud kliknete na tlačítko „filtrovat“, naopak filtr zrušíte stisknutím tlačítka „zrušit filtrování“. Řadit můžete podle libovolného sloupce. Řazení podle sloupce provedete jednoduchým kliknutím na název sloupce v záhlaví tabulky. Opakovaným klikáním na název sloupce docílíte změny směru řazení. Jsou možné dva směry: sestupně a vzestupně.

Obrázek G.4: Uživatelský manuál – filtr a řazení v seznamech

78


Stránkování v seznamech Pokud seznam obsahuje hodně záznamů, zobrazí se vám pouze určitý počet z nich a zároveň taky možnost stránkování umístěná nad i pod tabulkou. Pomocí stránkování se můžete pohybovat o jednu stránku vpřed či vzad nebo rovnou na konec či začátek. Stránkování vám také ukazuje, na jaké straně se zrovna nacházíte.

Obrázek G.5: Uživatelský manuál – stránkování

G.2

Pro uživatele, kteří nemají pouze práva pro zaměstnance

Nejprve si přečtěte příručku pro zaměstnance, jelikož ta je platná a směrodatná i pro vás. Oproti zaměstnancům se vám v levé části objevilo nové menu „Systémové menu“, kde jsou zobrazeny pouze akce, na které máte přidělená práva. Možných akcí je opravdu mnoho a je zbytečné je všechny vypisovat, jelikož jsou všude stejné. Proto je pro vás připraven souhrnný popis těchto akcí a zároveň popis akcí nebo událostí, které jsou v rámci aplikaci jedinečné. Přidání a úprava záznamu Dojde k zobrazení příslušného formuláře a vašim úkolem je ho pouze správně vyplnit. Formulář navíc obsahuje vysvětlivky u políček, kde mohou vzniknout nejasnosti. Pokud uděláte nějakou chybu a formulář odešlete, tak vás systém upozorní, kde jste ji udělali a co požaduje za hodnotu. Mazání záznamu Po kliku na odkaz „smazat“ v příslušném řádku tabulky nebo v navigační liště u detailu záznamu se vás systém zeptá, zda opravdu chcete daný záznam odstranit. Po odsouhlasení dojde k trvalému vymazání záznamu. Vytvoření čárového kódu Čárové kódy vytvářejte výhradně přes odkaz „přidat čárový kód“ v navigační liště u detailu zaměstnance nebo v příslušném řádku tabulky. Díky tomu předejte možných problémům způsobeným nesprávným zadáním textové podoby čárového kódu. Generování karty zaměstnance Klikněte na odkaz „vygenerovat kartu“ v příslušném řádku tabulky nebo v navigační liště u detailu čárového kódu zaměstnance. Zobrazí se stránka s náhledem na kartu, kterou můžete vygenerovat ve formátu PDF stisknutím tlačítka „vygeneruj PDF“. Kontrola přítomnosti zaměstnanců Klikněte na odkaz „kontrola přítomnosti zaměstnanců“ u položky „docházka“ v menu. Zobrazí se formulář, kde si vyberete, koho chcete kontrolovat (více lidí jde vybrat pomocí

G.2. PRO UŽIVATELE, KTEŘÍ NEMAJÍ POUZE PRÁVA PRO ZAMĚSTNANCE

79

přidržení klávesy Ctrl) a v jaký čas. Po stisknutí tlačítka „zkontrolovat“ se vypíší příslušné informace. Generování výplatních listů Klikněte na odkaz „vygenerovat mzdový podklad“ v příslušném řádku tabulky nebo v navigační liště u detailu mzdového podkladu zaměstnance. Úprava mzdových podkladů Pokud potřebujete upravit nějaké údaje pro generování výplatního listu, máte pak dvě možnosti pro uložení. Můžete mzdový podklad uložit s vašimi změnami bez následného přepočítání nebo s přepočítáním. Pozor, jakmile bude nastaven stav mzdového podkladu na „autorizováno“, tak už jej nebudete moci upravit. Přidávání nových proměnných dat zaměstnance Při přidání nových proměnných dat zaměstnance nikde nevyplňujete platnost těchto dat. Platnost stávajících dat se v daný okamžik ukončí a naopak novým datům od onoho okamžiku platnost začíná. Export detailního přehledu práce zaměstnanců Pokud chcete získat informace o práci zaměstnanců, máte tři možnosti: • Klikněte na odkaz „export detailního přehledu práce všech zaměstnanců“ u položky „zaměstnanci“ v menu. • Klikněte na odkaz „export přehledu o práci“ v příslušném řádku tabulky nebo v navigační liště u detailu zaměstnance. • Klikněte na odkaz „export přehledu o práci“ v příslušném řádku tabulky nebo v navigační liště u detailu oddělení firmy. Tímto si zároveň vyberete zaměstnance, o které máte zájem. Nyní ještě musíte vyplnit, za jaké období chcete export provést. Po stisknutí tlačítka „vygenerovat“ budete mít k dispozici příslušná data ve formátu CSV.

80


Příloha H

Obsah přiloženého CD • Dokumenty: adresář obsahuje bakalářskou práci ve formátu PDF a TeX. • Dochazkovy-system: adresář obsahuje zdrojové kódy aplikace.

81

Na tomto místě bude oficiální zadání vaší práce

Recommend Documents