SZAKDOLGOZAT MUNKAIDŐ- ÉS TEVÉKENYSÉG-NYILVÁNTARTÓ WEBALKALMAZÁS FEJLESZTÉSE

SZAKDOLGOZAT MUNKAIDŐ- ÉS TEVÉKENYSÉG-NYILVÁNTARTÓ WEBALKALMAZÁS FEJLESZTÉSE

Készítette: Zádeczki László Gazdaságinformatikus Szak (BSc)

Témavezető: Elek Tibor mérnöktanár Konzulens: Dr. Házy Attila egyetemi docens Miskolci Egyetem, 2015

MISKOLCI EGYETEM Gépészmérnöki és Informatikai Kar Analízis Tanszék

Szám:..................................

SZAKDOLGOZAT FELADAT

Zádeczki László

gazdaságinformatikus jelölt részére.

A szakdolgozat tárgyköre: Webalkalmazás A szakdolgozat címe: Munkaidő- és tevékenység-nyilvántartó webalkalmazás fejlesztése A feladat részletezése: A feladat egy webalkalmazás készítése, amely egy projektorientált szervezet dolgozóinak különböző projektfeladatokra, tevékenységekre fordított idejét tartja nyilván. A programmal pontosan számon tartható, hogy egy dolgozó mely feladatok elvégzéséért felelős és azokra mennyi időt fordított. A bejegyzett időtartamok alapján összegzések és kimutatások tekinthetők meg, amelyek segítik a projektmenedzsereket és vezetőket a megfelelő döntések meghozatalában. A feladat megoldása ASP.NET MVC technológia felhasználásával C# nyelven történik.

Témavezető(k): Elek Tibor mérnöktanár Konzulens(ek): Dr. Házy Attila egyetemi docens A feladat kiadásának ideje: 2014. szeptember 15.

.................................................... Dr. Szigeti Jenő tanszékvezető

2

1. szükséges (módosítás külön lapon). A szakdolgozat feladat módosítása nem szükséges. ................................. dátum

...................................................................... témavezető(k)

2. A feladat kidolgozását ellenőriztem: témavezető (dátum, aláírás): ............................................. ............................................. .............................................

konzulens (dátum, aláírás): ………............................................ ......………...................................... .................………...........................

3. A szakdolgozat beadható: ................................. dátum 4. A szakdolgozat

...................................................................... témavezető(k)

........................... szövegoldalt ........................... program protokollt (listát, felhasználói leírást) ........................... elektronikus adathordozót (részletezve) ........................... ........................... egyéb mellékletet (részletezve) ...........................

tartalmaz. ................................. dátum

...................................................................... témavezető(k)

5. bocsátható. A szakdolgozat bírálatra nem bocsátható. A bíráló neve: .....................…………..……………………............................................ …............................. dátum

……………..…............................................ tanszékvezető

6. A szakdolgozat osztályzata a témavezető javaslata: …..…………….................... a bíráló javaslata: ……….……………...................... a szakdolgozat végleges eredménye: ......................... Miskolc, ......................................... ........................................................... a Záróvizsga Bizottság Elnöke

3

EREDETISÉGI NYILATKOZAT

Alulírott ……………………………………………………….; Neptun-kód:………………… a Miskolci Egyetem Gépészmérnöki és Informatikai Karának végzős, ………………………………………………………………………………………………….. szakos hallgatója ezennel büntetőjogi és fegyelmi felelősségem tudatában nyilatkozom és aláírásommal igazolom, hogy ……………………………………………………………………………………………… című

szakdolgozatom/diplomatervem saját, önálló munkám; az abban hivatkozott

szakirodalom felhasználása a forráskezelés szabályai szerint történt. Tudomásul veszem, hogy szakdolgozat esetén plágiumnak számít: -

szószerinti idézet közlése idézőjel és hivatkozás megjelölése nélkül;

-

tartalmi idézet hivatkozás megjelölése nélkül;

-

más publikált gondolatainak saját gondolatként való feltüntetése.

Alulírott kijelentem, hogy a plágium fogalmát megismertem, és tudomásul veszem, hogy plágium esetén szakdolgozatom visszautasításra kerül. Miskolc, .............év ………………..hó ………..nap

…….……………………………….… Hallgató

4

Tartalomjegyzék 1. Bevezetés .............................................................................................................. 7 2. Az alkalmazott technológia bemutatása ................................................................. 9 2.1.

Az ASP.NET .................................................................................................. 9

2.2.

Az MVC architektúra és az ASP.NET MVC................................................... 9

2.3.

Példaprogram ............................................................................................... 10

2.3.1.

A modell réteg ....................................................................................... 11

2.3.2.

A megjelenítési réteg.............................................................................. 12

2.3.3.

A kontroller réteg ................................................................................... 14

2.4.

JavaScript ..................................................................................................... 16

2.5.

jQuery .......................................................................................................... 16

2.6.

AJAX ........................................................................................................... 17

3. Követelmény analízis .......................................................................................... 18 3.1.

Általános elvárások....................................................................................... 18

3.2.

A feladat objektum ....................................................................................... 19

3.3.

Szoftver követelmények ............................................................................... 19

4. Specifikáció ........................................................................................................ 20 4.1.

Az alkalmazás felhasználói ........................................................................... 20

4.2.

Az alkalmazás funkciói ................................................................................. 22

4.2.1.

Autentikáció és autorizáció .................................................................... 22

4.2.2.

Címkék megadása és feladat kiválasztása ............................................... 23

4.2.3.

Időmérés ................................................................................................ 23

4.2.4.

Mért idők listázása ................................................................................. 23

4.2.5.

Jelentés megtekintése ............................................................................. 24

4.2.6.

Projektek és feladatok létrehozása, menedzselése ................................... 24

4.2.7.

Adminisztrátori funkciók ....................................................................... 24

5. Tervezés .............................................................................................................. 25 5.1.

Adatbázisterv ................................................................................................ 25

5.2.

A felhasználói felület megjelenésének és működésének tervezése ................ 27

5.2.1.

Menüsáv terve ........................................................................................ 27

5.2.2.

Home – Főoldal terve ............................................................................. 28

5

5.2.3.

Report – Összesítő oldal terve ................................................................ 30

5.2.4.

Control – Vezetői oldal terve ................................................................. 31

5.2.5.

Progress Report oldal terve .................................................................... 32

5.2.6.

Project Management oldal terve ............................................................. 32

5.2.7.

Administration oldal terve ...................................................................... 32

5.3.

A modell réteg osztályainak terve ................................................................. 33

5.4.

A kontroller réteg osztályainak terve ............................................................ 34

6. Implementálás ..................................................................................................... 35 6.1.

Az implementáláshoz használt szoftverek ..................................................... 35

6.2.

Adatkezelés .................................................................................................. 35

6.3.

Autentikáció és autorizáció ........................................................................... 38

6.4.

Adatellenőrzés .............................................................................................. 40

6.5.

Címkék megadása, feladat kiválasztása ......................................................... 41

6.6.

Az időmérés folyamata ................................................................................. 42

6.7.

Kimutatás megjelenítése ............................................................................... 43

7. Összefoglalás és jövőkép ..................................................................................... 45 8. Summary ............................................................................................................. 46 9. Irodalomjegyzék ................................................................................................. 47 10.

Melléklet.......................................................................................................... 48

6

1. Bevezetés Szakdolgozatom témája egy webes felületű munkaidő- és tevékenység-nyilvántartó alkalmazás elkészítése. A szoftver célja, hogy egy projektorientált szervezet dolgozói számára feladataikra fordított tényleges munkaidejük valós időben történő naplózását biztosítsa. Egy-egy naplózási folyamatot a felhasználó indít el, majd az adott tevékenység szüneteltetését vagy elvégzését követően befejezi a másodpercekben történő mérést. A két esemény között eltelt idő részidőket képez, amelyek alapján az egyes feladatokra fordított idő összesíthető. Az összesítések segítségével a feladatok készültsége folyamatosan nyomon követhető, valamint következtetések vonhatóak le a jövőbeni megrendelésekre vonatkozóan. A program a DACHS Hungary Kft. számára készül, így cél az is, hogy a gyakorlatban is megállja a helyét. A DACHS Hungary Kft. 2013 folyamán alakult a DACHS Computing & Biosciences GmbH magyarországi fióktelepének utódaként. Az anyavállalatot 1998-ban alapították Bázelben, majd rövidesen Budapesten és Miskolcon is megnyíltak az irodák. Fő tevékenysége a tartalom és dokumentumkezelő rendszerek fejlesztése és támogatása, amelyben több mint 15 éves tapasztalattal rendelkezik. Ügyfelei főként svájci központú gyógyszervállalatok. A dolgozat írásának idején már több mint egy éve a cégnél dolgozom diákmunka keretében alkalmazás fejlesztőként és a szakmai gyakorlatomat is itt töltöttem. A DACHS, mint projektorientált cég már hosszú ideje használ tevékenység nyilvántartó programot. Funkcionalitását tekintve hasonló, mint a dolgozatom témáját képző szoftver, ugyanakkor működésében és felépítésében eltér. A régi szoftver egy nyílt forráskódú, fejlesztői által kissé elhanyagolt alkalmazás a DACHS saját igényeire szabva, amelynek alapvető működését a projektek/csoportok/feladatok szigorú hierarchiája jellemzi. Az évek során a feladatok és a projekt-verziók komplexitásának növekedésével ez a szemlélet nagyon rugalmatlanná tette a programot. Egy projekthez tartozó csoportot vagy alprojektet tovább már nem lehet bontani, a feladatok ezen túli megkülönböztetése már csak a feladat nevében lehetséges például verziószám feltüntetéssel, ami viszont nehezen átláthatóvá teszi a feladatok halmazát. 7

További érv, ami a lecserélés mellett szól, hogy átalakítása csak nagy időköltséggel lenne megvalósítható. Enne oka, hogy a program php nyelven, nem objektum orientált szemlélettel készült. Az egyébként is nehezebben karbantartható és „debugolható” php kódot sokan módosították közel öt éves működése során az éppen megjelenő problémák és felmerülő igényeknek megfelelően, így egy komolyabb, a program alapvető struktúráját érintő változtatás az egész rendszerre kihatna és csak a teljes alkalmazás átírásával lehetne megvalósítani. Az új alkalmazásban használt rendszerezési megközelítés szintén a feladatokat emeli központi szerepbe, azonban a kötött és nehezen megváltoztatható hierarchia elhagyásával. Különböző csoportok létrehozásához címkéket használ, amelyeket a feladatokhoz rendel. Egy címke lehet például a projekt, a verziószám, a feladatot végző neve, a projektmenedzser neve vagy minden olyan elem, amely a feladatra nézve azonosító vagy csoportosító szereppel bír. Az így kialakított rendszer rugalmas, mivel egy-egy újabb címkével bármikor bővíthető egy feladat vagy feladat csoport, valamint a feladatok hatékonyabban kereshetők és tarthatók nyílván. A program ASP.NET MVC keretrendszerrel készül, amely technológiát elsősorban megismerési célból választottam. A webes világgal programozás szempontjából egyetemi tanulmányaim során ismerkedtem meg, leginkább elméleti szinten, gyakorlatot a DACHS-nál szereztem belőle, főleg ASP.NET Web Forms területen. Az MVC, mint modern és könnyen tanulható technológia ezután keltette fel az érdeklődésemet és a szakdolgozat készítést alkalmasnak találtam a tématerület elsajátítására. Szakdolgozatom első részében ismertetem a megvalósítás során felhasznált technológiákat, az MVC főbb részeit és jellemzőit. Ezt követően az alkalmazás követelményeit határozom meg, először általánosan a felhasználói oldalról, majd ezek specifikálása történik meg. Ezután a tervezési fázisban az adatbázis, a felhasználói felület és az egyes osztályok terve kerül részletezésre a meghatározott követelmények alapján. Végezetül az implementálási folyamat fontosabb lépéseit és az elkészült programot mutatom be.

8

2. Az alkalmazott technológia bemutatása 2.1. Az ASP.NET Az ASP.NET egy szerver oldali, dinamikus weboldalak és webalkalmazások készítését lehetővé tévő technológia, amely a Microsoft fejlesztése. Első verziója 2002-ben jelent meg a .NET keretrendszer tagjaként. Célja az ASP (Active Server Pages) web programozási technológia továbbfejlesztése, újfajta programozási modell és infrastruktúra bevezetése volt. Az ASP.NET önmagában nem egy nyelv, mivel bármely .NET-et támogató nyelven lehet használni. Ennek oka, hogy a .NET részét képző Common Language Runtime futtató környezetre épült, így a programozók különböző, a .NET által támogatott nyelven (pl. C#, Visual Basic, stb.) írhatnak ASP.NET programokat. Három különböző fejlesztési modellt támogat: Web Pages, Web Forms és az MVC modell. Egyik kulcsfontosságú funkciója az úgynevezett esemény alapú programozási modell. Az ASP.NET weboldalak és az azokon elhelyezett vezérlő elemek felhasználói interakciók következtében meghatározott sorrendben eseményeket váltanak ki, amit az oldal életciklusának nevezünk. A kliens egy esemény kiváltását HTTP kérés formájában

közli

a

szerverrel,

amely

átadja

a

vezérlést

a

megfelelő

eseményvezérlőnek. A folyamat végén a válasz generált HTML kód formájában kerül visszaküldésre, amit a kliens könnyen megjeleníthet. 2.2. Az MVC architektúra és az ASP.NET MVC Az MVC (Model – View – Controller) a szoftverfejlesztés során széles körben alkalmazott szerkezeti minta. Fő tulajdonsága, hogy szétválasztja az alkalmazást a különböző funkciókat megvalósító részek mentén. A gyakorlatban ez azt jelenti, hogy elkülöníti az adatok kezelését és az üzleti szabályokat a felhasználói felület működéséért és megjelenítéséért felelős komponensétől azzal, hogy egy közbenső elemet vezet be, a vezérlőt. Ilyen módon egy MVC alkalmazás három jól szeparálható, egymással laza kapcsolatban álló rétegből épül fel: a modell réteg, amely az adatok tárolásáért felel és tartalmazza az üzleti logikát; a nézet, ami meghatározza, hogy az 9

adatok hogyan jelenjenek meg; valamint a vezérlő, ami kezeli az előbbi kettőt és kommunikál a klienssel.

1. ábra – Az MVC szerkezete

Az MVC hármas tagolásának számos előnye van, amelyek megkönnyítik az alkalmazásfejlesztők

munkáját.

Az

elkülönülő

rétegekkel

való

építkezésnek

köszönhetően, megfelelő tervezés után több fejlesztő is dolgozhat párhuzamosan ugyanazon az alkalmazáson, így jelentősen felgyorsulhat egy-egy nagyobb projekt elkészítése, illetve lehetővé válik terület specifikus szakemberek (például front-end fejlesztők) alkalmazása is. További jelentős előnye, hogy megvalósítása erősen strukturált rendszert eredményez. Az egymástól független modulokat külön-külön lehet fejleszteni, tesztelni, karbantartani, illetve más programokban újrafelhasználni. Az ASP.NET MVC az

ASP.NET keretrendszerre épülő

innovatív webes

szoftverfejlesztési környezet, amely implementálja a model-view-controller tervezési mintát és egy alternatív módot nyújt a webes alkalmazások készítésére. Első verzióját 2009-ben adták ki, azonban a webes világ folyamatos fejlődéséhez igazodva évente jelenik meg újabb változata jelentős újításokkal. Forráskódja a kezdetektől hozzáférhető, így a hibajavítás és az új ötletek megvalósítása folyamatos és naprakész. A következőkben egy példa programon keresztül fogom bemutatni részletesebben az ASP.NET MVC felépítését és működését. 2.3. Példaprogram A példaprogram egy leegyszerűsített felhasználó nyilvántartó felület, ahol a felhasználók nevét, lakhelyét és email címét lehet megadni, valamint megtekinteni a már regisztráltakat és a listán az egyes bejegyzéseket szerkeszteni, törölni. Az 10

alkalmazás - ahogy a legtöbb webes alkalmazás - fő feladata, hogy kiszolgálja a kliens számítógépén megjelenő dinamikus weboldalakat. Egy MVC oldal életciklusát a böngészőből érkező kérés indítja el, amelyet a keretrendszer a kontroller egy metódusának ad át. Ez a metódus hozza létre a modellpéldányt, majd a szükséges műveletek elvégzése után átadja azt a megjelenítési rétegnek. Ugyanakkor elmondható, hogy nem minden kérés igényel modell objektumot, ekkor a vezérlő egyszerűen csak visszaadja a kért erőforrást. 2.3.1. A modell réteg A modell rétegben találhatóak az összetartozó adathalmazokat reprezentáló osztályok és az üzleti logika, jelen esetben a UserModel (felhasználók) osztály. Ezen osztály példánya elérhető a kontroller és azon keresztül akár a nézet számára is. Szerepe, hogy az alkalmazás szempontjából fontos értékek tárolása rendszerezve történjen meg a memóriában. Leggyakrabban egy modell objektum az állapotát adatbázisban tárolt adatok alapján kapja meg, a megváltozott adatok pedig oda kerülnek elmentésre. A példaprogramban az adatbázis ADO.NET Entity Framework keretrendszerrel valósul meg,

ami

egy

objektum-relációs

leképző

technika

(ORM),

segítségével

objektumorientáltan kezelhetőek a táblaadatok. Több szemléletmód szerint is alkalmazható:

adatbázis

először,

modell

először

és

kód

először

elv.

A

példaprogramban a kód először elvet alkalmazom, amely lehetővé teszi, hogy az adatbázis tábla automatikusan generálódjon a modell osztály kódja alapján. public class UserModel { public int Id { get; set; }

A

UserModel

tulajdonsággal

osztály

(property-vel)

[Required] [Display(Name = "Név")] [StringLength(50)] public string Name { get; set; }

rendelkezik: a felhasználó azonosítója,

[Required] [Display(Name = "Város")] [StringLength(50)] public string Address { get; set; }

tulajdonságok

neve, lakhelye és email címe. A

attribútumokkal,

elláthatók

olyan

amelyek

meta-

információkat tartalmaznak a [Display(Name = "Email cím")] [StringLength(50)] public string Email { get; set; } }

négy

view

HTML generáló metódusai számára. Vonatkozhatnak validációra, típusra,

11

szerkeszthetőségre, megjelenítésre és még sok minden másra is. Akár arra is van lehetőség, hogy saját attribútumot definiáljunk. Szerepük, hogy az adatmodell rendelkezzen egy univerzális definícióval. Az attribútumok az Entity Framework számára is lényegesek. Ezen információk alapján tudja, hogy milyen mezőtípusokat és mezőhosszakat használjon a táblák mezőinek létrehozásakor. 2.3.2. A megjelenítési réteg A megjelenítési rétegben kapnak helyet azok a sablonok (template-ek), amelyek alapján, a kliens oldalon megjelenik a kívánt tartalom az adatmodellt felhasználva. Tartalmuk statikus (HTML nyelvi elemek) és dinamikus (C# vagy VB kód) részekből épül fel. A dinamikus tartalom HTML kódba való beágyazására több megvalósítás is létezik. Ezek közül egyik legnépszerűbb a Razor jelölő nyelv, amely az MVC harmadik verziójában jelent meg. A C# nyelvre épül és más jelölőkkel ellentétben nem igényli a kód blokkok lezárását, a nyitás ’@’ karakterrel történik. Előnye, hogy minimális átmenetet biztosít a HTML és a C# kód között, könnyen áttekinthető, kompatibilis a Unit tesztelési módszerrel. Egy Razor template kiterjesztése C# esetén .cshtml, VB használatakor pedig .vbhtml. A példaprogramban az Index.cshtml az alkalmazás főoldala, ez fog megjelenni az alkalmazás indításakor. Tartalmát az alábbi kódrészlet mutatja. @model IEnumerable<UserRegAndDetails.Models.UserModel> ...

@Html.ActionLink("Hozzáadás", "Create")

...

@foreach (var item in Model) { ...

}

@Html.DisplayNameFor(model => model.Name)
@Html.DisplayFor(modelItem => item.Name)	@Html.ActionLink("Szerkesztés", "Edit", new { id=item.Id }) | @Html.ActionLink("Törlés", "Delete", new { id=item.Id })

...

12

Első sora @model kulcsszóval kezdődik, amelyet követően adható meg a view-ban használni kívánt modell, gyakorlatilag a view típusa. A view-ban ezután egyszerűen lehet elérni a modell objektumot a Model property-vel vagy a Html osztály elemgeneráló metódusainak argumentumai között megadott lambda kifejezésekkel. A kontroller által átadott UserModel típusú objektumot egy foreach ciklus dolgozza fel, amely egy táblázatot állít elő soronként. Itt megfigyelhető a korábban említett átláthatóság: a C# kód „elvegyül” a HTML jelölések között anélkül, hogy megtörné az olvasáshatóságot. A táblázat utolsó oszlopában a linkek találhatóak. MVC esetén ezek nem konkrét weboldalakra mutatnak, hanem kontroller osztályok metódusaira. Előállításukhoz használható ActionLink metódus argumentumai között a második (Edit és Delete) a kontroller egy-egy metódusára utal. Azon linkek esetében, amelyek ugyanarra a vezérlő osztályra mutatnak, ahonnan a megjelenítés történt, nem szükséges külön megjelölni a kontrollert. Az utolsó argumentum (RouteValue) egy gyűjtemény, amelyben össze lehet gyűjteni az URL-hez kapcsolható összes paramétert. Például Kis István nevű felhasználó adatainak szerkesztése a következő URL-lel érhető el: User\Edit\3, ahol a User a kontroller osztály neve, az Edit pedig a metódus, amelynek átadódik Kis István azonosítója, a 3-as szám. A fenti kódrészletnek az alábbi oldal felel meg:

2. ábra – Felhasználók listája

13

2.3.3. A kontroller réteg A kontroller réteg osztályok halmaza, amelyek fogadják a kliens kéréseit, majd válaszolnak azokra. Minden kontroller osztály neve kötelezően a Controller szóval kell, hogy végződjön. Az, hogy egy klienstől érkező kérést mely osztály metódusa dolgoz fel, a kérésben szereplő URL alapján dől el. Például, ha a „Hozzáadás” linkre kattintunk, akkor a kérésben a http://localhost:6519/User/Create URL fog szerepelni, amelyből a keretrendszer (a route konfiguráció alapján) tudja, hogy a kérést a UserController osztály Create() metódusa kell, hogy megkapjon. Jelen esetben a Create() metódus nem csinál egyebet, mint megjeleníti a kívánt oldalt. Természetesen a route konfiguráció is szabadon változtatható. A kimenet - azaz, hogy melyik view template-ből fog a válasz HTML tartalom generálódni – alapesetben szintén névegyezőség alapján dől el, de a View metódusnak van paraméterezett változata is, ahol megadható a használni kívánt séma. Alapesetben a Create() metódushoz a Create.cshtml template tartozik, így az alábbi metódus szerint a „Hozzáadás” űrlap (3. ábra) HTML kódja fog a válaszban szerepelni. public ActionResult Create() { return View(); }

3. ábra – Felhasználó hozzáadása

14

Egy kontroller metódus a megjelenítés mellett természetesen képes egyéb komplexebb műveletek elvégzésére is, mint például validációs szabályok ellenőrzésére, az adatmodell módosítására és elmentésére. Ha a felhasználó a „Hozzáadás” gombra kattint, akkor egy POST kérés küldődik a szerver felé benne az űrlapon megadott modell objektum adataival. Ekkor ugyanazon URL szerepel a kérésben, mint a „Hozzáadás” gomb esetében, azonban lehetőség van a kérés típusa (GET vagy POST) alapján is irányítani, úgy hogy megfelelő attribútumokkal látjuk el a metódust ([HttpPost]). [HttpPost] [ValidateAntiForgeryToken] public ActionResult Create(UserModel usermodel) { if (ModelState.IsValid) { db.UserModels.Add(usermodel); db.SaveChanges(); return RedirectToAction("Index"); } return View(usermodel); }

A

Create

metódus

fejléce

előtt

szereplő attribútumok szerepe hasonló a modell osztályban használtakéhoz. A ValidateAntiForgeryToken

egy

biztonsági ellenőrzés elvégzését jelzi, amely megakadályozza, hogy hamis, nem a megfelelő klienstől érkező,

esetleges támadási céllal küldött kérést dolgozzon fel a metódus. A metódus paraméterként várja az elkészített modell objektumot (adatkötés valósul meg), és ha nem történt validációs hiba (ModelState.IsValid értéke igaz), akkor az adatbázis objektum megfelelő entitásához hozzáadja a modellt, majd elmenti a változásokat, aminek hatására a tényleges adatbázis is frissül. Végezetül átirányítja a vezérlést az Index() metódusnak, amely az alábbi kódot végrehajtva megjeleníti a táblát (2. ábra) az aktuális adatokkal. public ActionResult Index() { return View(db.UserModels.ToList()); }

Megfigyelhető, hogy a View metódusban ott szerepel argumentumként a UserModel generikus gyűjtemény, ahogy azt a template várja.

15

2.4. JavaScript A JavaScript a webes alkalmazások, honlapok készítésénél előszeretettel alkalmazott kliensoldali scriptnyelv, amely HTML dokumentumban önállóan futó alkalmazás, szintaktikája hasonlít a C és C++ nyelvekre. Segítségével az alapvetően statikus weboldal dinamikusabbá, felhasználóbarátabbá és interaktívabbá tehető. A kód a HTML weboldallal együtt kerül betöltésre. Az egyes utasítások és függvények értelmezését a kliens böngészőprogramja végzi, ezek futtatása történhet betöltés után közvetlenül, de különböző események bekövetkezésekor is. Előnye, hogy a kliensen futva gyakorlatilag valós időben kezelhetőek le a különböző egyszerűbb események, ezáltal interaktívabbá teszi a weboldalt anélkül, hogy a szerver erőforrásait használná. Platformfüggetlen, futtatásához csak egy böngésző alkalmazás szükséges. Hátránya viszont, hogy nem minden böngésző értelmezi egyformán ugyanazt a kódot. További problémát jelenthet, hogy a felhasználók egyszerűen hozzáférhetnek a kódhoz, így megváltoztathatják azt vagy módosíthatnak olyan értékeket és az azokra vonatkozó validációs korlátokat, amelyek további kliens és szerveroldali feldolgozás tárgyát képzik. Ezen probléma lehetséges megoldása többszörös adatellenőrzési szintek megvalósítása ott, ahol adatok bekérése történik meg a klienstől: kliens oldali ellenőrzés, amely azonnali visszajelzésével kényelmesebbé teszi a használatot, majd a szerverre megérkező adatok újbóli ellenőrzése. 2.5. jQuery A jQuery egy napjainkban nagy népszerűségnek örvendő JavaScript keretrendszer. Célja, hogy a JavaScript és a HTML kód között hidat képezzen azonosítókat és eseményvezérlőket használva. Egyszerűsíti és használhatóbbá teszi a JavaScript programozást és a DOM elemek elérését, valamint az AJAX kérések megvalósítását. Előnye, hogy a JavaScript-hez hasonlóan a jQuery is részletes dokumentációval rendelkezik. Tömörsége miatt gyorsabban használható mind a fejlesztés, mind a végrehajtás szempontjából. A HTML és CSS felhasználásával látványossá és

16

rendkívül felhasználóbaráttá tud tenni egy weboldalt. Nagy és aktív közösséggel rendelkezik, amelynek köszönhetően rengeteg előre megírt jQuery plugin érhető el, valamint hamar javításra kerül egy-egy biztonsági rés, hibás vagy nem eléggé hatékony kód. Számos bővítménye révén asztali alkalmazásokhoz hasonlatos viselkedés is megvalósítható viszonylag kevés erőforrás használata mellett. Hátrányai között lehet megemlíteni, hogy egy rosszul megírt kód, régebbi böngészők vagy kisebb teljesítményű számítógépek esetén lassíthatja vagy akár ellehetetlenítheti a weboldal használatát, ezért alkalmazása előtt célszerű felmérni a felhasználók által leggyakrabban használt böngészőket, illetve különböző konfigurációkon is tesztelni. 2.6. AJAX Az AJAX (Asynchronous JavaScript and XML) kis adattartalmú kérések aszinkron módon történő küldését lehetővé tevő web-fejlesztési technika. Az aszinkronitás ebben az esetben azt jelenti, hogy a kérés elküldése nem jár azzal, hogy a böngésző átirányít vagy vár a válaszra, így a felhasználó a feldolgozás alatt is képes a weboldal használtára. További előnye, hogy a szerver válaszát a teljes oldal újratöltése nélkül képes megjeleníteni, ezzel fokozva a felhasználói élményt és a böngészés vagy a munka folyamatosságát, valamint kisebb adatforgalmat generál a kliens és a szerver között. Ahogy a neve is mutatja, JavaScriptre épül, ugyanakkor (ha lehetséges) célszerűbb a jQuery könyvtárban található ajax függvénnyel történő használata, amely rövidebb és egyszerűbb kódot eredményez. Hátrányaként említhető, hogy a böngésző vissza és előre navigáló funkciója a teljes oldalbetöltés nélküli kérések miatt használhatatlanná válik, azaz például a vissza gomb a böngészési lánc azon legutolsó pontjához tér vissza, ami még nem AJAX kéréssel lett megjelenítve, ugyanakkor megoldások már léteznek erre a problémára.

17

3. Követelmény analízis 3.1. Általános elvárások A cél egy olyan webes felületű munkaidő és tevékenység nyilvántartó program elkészítése, amelyet a DACHS Hungary Kft. alkalmazottai napi szinten használni fognak. A szoftver elsődleges célja, hogy a dolgozók különböző feladataikra fordított idejüket az alkalmazással rögzíteni tudják, és az így előállt adatok pedig segítsék a vezetők döntéseit. A feladatok fő csoportosítási szintje a projektek, ugyanakkor a címkézés módszerével egyéb csoportoknak (például verziók, alprojektek) is tetszőlegesen kialakíthatónak kell lennie. A cégnél a projekt fogalom egy-egy nagyobb megrendelési csoportot jelent, amely alá kisebb alprojektek és csoportok, valamint az azokhoz rendelt feladatok tartoznak. A projekteket a vezetők vagy az erre kijelölt menedzserek definiálják és hozzák létre. Ennek során jellemző feladataik, hogy a projektek élére projektmenedzsereket nevezzenek ki, a már felmerült megrendelői igényeket és konkrét elvárásokat a megvalósíthatóság szempontjából könnyen érthető formára hozzák és ezek alapján kezdeti feladatokat definiáljanak, csoportokat alakítsanak ki, határidőket állítsanak fel. A webalkalmazásom egyrészt ezen folyamatok eredményét kell, hogy befogadja, nyilvántartsa és felhasználja működéséhez, másrészt pedig biztosítania kell a tevékenységek rögzítését,

amely egy előzetesen

kiválasztott feladatra

való

munkaidőmérést jelent. Ennek elindítása és leállítása a felhasználó felelőssége. A rögzített tevékenységek alapján egy áttekintő, összefoglaló felületet kell adnia annak a felhasználónak, akihez a bejegyzések tartoznak. Ugyanakkor még fontosabb feladata, hogy a mérési adatok és a feladatok jellemzőinek felhasználásával ugyanezt biztosítsa a döntéshozók számára is, azaz információt nyújtson az egyes tevékenységek és projektek állapotáról, készültségi fokáról, a dolgozók tényleges munkaidejéről. Ezen összesítés elsődleges célja, hogy a kitűzött határidők betartása vagy átlépése ellenőrizhető legyen, valamint láthatóvá váljon a munkaórák száma mind feladat, mind projekt vagy egyéb tetszőlegesen megadott szűrési csoport szintjén.

18

A projektek élettartama alatt a projektmenedzserek végzik a feladatok kiosztását és felügyeletét. Képesnek kell lenniük az alkalmazás segítségével például megjegyzések írására, határidők és prioritások módosítására és szükség esetén a feladatok körének bővítésére, újraosztására. 3.2. A feladat objektum A megfogalmazott követelmények alapján kijelenthető, hogy a program központi elemei a feladatok lesznek. Egy feladat minden esetben egy magasabb szintű elem alá tartozik, amely lehet egy projekt, alprojekt vagy egyéb csoport. Egy feladat tulajdonságai közé tartozik a megnevezése, a hozzá rendelt felhasználók neve, a feladat leírása, határideje, elvégezéséhez szükséges becsült időtartama, prioritása, aktuális állapota. Beazonosításuk úgynevezett címkézési módszerrel kell, hogy megvalósuljon. Egy címke lehet a szülő projekt, a projektmenedzser, azon felhasználók, akik birtokolják a feladatot, valamint egyéb csoportosítást jelentő megnevezések, mint például alprojekt vagy verziószám. A címkézés elsődleges célja a hierarchikus rendszer szigorúságának lazítása és annak biztosítása, hogy a felhasználók egyszerűen megváltoztathassák, testre szabhassák a hierarchiát. A címkék között

a

projekt

címkék

megkülönböztetett

szerepet

kell,

hogy

kapjanak

alapértelmezett csoportosítási célból. 3.3. Szoftver követelmények A szoftver az ASP.NET MVC 5-ös verziójával készül Microsoft Visual Studio fejlesztői környezetben .NET Framework 4.5.1 felhasználásával. A kész szoftver üzemeltetéséhez Windows Server 2008 SP2 vagy annál újabb operációs rendszert futtató szerver szükséges majd. A megkövetelt .NET Framework a 4.5.1 vagy annál újabb verzió. Az adatbázis tárolásához és kezeléséhez Microsoft SQL Server 2008 vagy annál újabb szükséges. Felhasználói oldalról nincsenek különösebb követelmények, az alkalmazás oldalai bármilyen böngészőprogramból megtekinthetőek, mint például Internet Explorer, Chrome, FireFox, Opera, stb. 19

4. Specifikáció 4.1. Az alkalmazás felhasználói A követelmények alapján az alkalmazás felhasználóit három csoportba lehet sorolni: normál felhasználó, projektmenedzser, vezető. Ugyanakkor szükség lesz egy negyedik, adminisztrátor szerepkörre is, aki a felhasználókat létrehozza. Minden csoport csak a saját jogkörének megfelelő funkciókat érheti el, azonban egy felhasználó több szereppel is rendelkezhet, így például egy normál felhasználó megkaphatja meglévő tulajdonságai

mellé

a

vezető

minden

képességét

is.

Alapesetben

minden

felhasználónak rendelkeznie kell a normál szerepkörrel. A programtól elvárt funkcionális követelményeknek megfelelő használati eseteket a 4. ábrán látható használati eset diagram foglalja össze, illetve a következőkben különkülön részletezem az egyes szerepkörökkel szemben támasztott követelményeket. Normál felhasználói szerepkör tulajdonságai:  Képes a hozzá rendelt feladatok közül választani, a kereséshez címkéket tud megadni.  Képes a kiválasztott feladatra fordított munkaidejét mérni.  Kiválasztott feladathoz szöveges megjegyzéseket tud hozzáadni.  Képes megadni és változtatni egy kiválasztott feladat állapotát. Lehetséges állapotok: open, in progress, in review, stopped, finished.  Új feladatokat képes létrehozni saját maga számára, az általa létrehozott feladatokat módosítani, törölni tudja.  Mért időbejegyzéseit képes megtekinteni, módosítani vagy törölni.  Képes utólag is munkaidőt hozzáadni egy feladathoz.  Saját bejegyzéseire vonatkozóan lekérdezéseket képes végezni, összesítést tud megtekinteni.  Képes figyelemmel követni a hozzá rendelt feladatok előrehaladását.

20

4. ábra – Használati eset-diagram

Projektvezetői szerepkör tulajdonságai:  Látja az irányítása alatt álló projekteket, azok tagjait.  Az általa vezetett projekthez képes új feladatokat hozzáadni, valamint ezekhez tud felhasználót rendelni.  A hozzá tartozó projektek feladatait képes szerkeszteni.  Kimutatásokat tud megtekinteni a projektek előrehaladására és azok résztvevőire vonatkozóan.

21

 A feladatokhoz írt szöveges megjegyzések útján tud kommunikálni a projekt résztvevőivel. Vezetői szerepkör:  Képes projekteket létrehozni, módosítani, törölni.  A projektek és a feladatok adatait képes szerkeszteni.  Egy létrehozott projekthez projektvezetőt és dolgozókat tud hozzárendelni, valamint ezeket képes módosítani, eltávolítani.  Látja a beosztottjai munkaidejét, valamint a projektek előrehaladását és ezekből készült kimutatásokat tud megtekinteni. Adminisztrátori szerepkör:  Képes a felhasználókat kilistázni, új felhasználót hozzáadni, adataikat módosítani, felhasználót törölni.  Új felhasználó hozzáadása során képes szerepkörökhöz rendelni a dolgozót. 4.2. Az alkalmazás funkciói 4.2.1. Autentikáció és autorizáció Az alkalmazást csak az adminisztrátor által előzetesen regisztrált felhasználók használhatják. Az alkalmazás használata előtt a felhasználóknak először be kell jelentkezniük érvényes felhasználónevükkel és jelszavukkal egy csak erre szolgáló oldalon. A bejelentkezési folyamat során meg kell állapítani a felhasználók jogkörét, jogköreit. A jogkörök az egyes funkciók elérése előtt is ellenőrzésre kell, hogy kerüljenek. Az alkalmazás bármely oldalának direkt, a böngésző címsorába írt URL-el történő megnyitása során ellenőrizni kell, hogy az adott felhasználó bejelentkezett-e már. Ha nem történt ilyen, akkor a bejelentkezési oldalt kell megjeleníteni. Ezen az oldalon a név és jelszó adatok megadása után azok ellenőrzésre kerülnek az adatbázisban. Helyességük esetén megjeleníthető a főoldal vagy azon oldal, ahonnan az átirányítás megtörtént, hiba esetén a felhasználó figyelmeztető üzenetet kap és továbbra is a

22

bejelentkezési oldal jelenik meg. Sikeres bejelentkezés esetén a felhasználó adatai eltárolódnak cookie-ban és a bejelentkezett állapot mindaddig fent kell, hogy álljon, amíg a felhasználó ki nem jelentkezik, be nem zárja a böngésző programot vagy manuálisan nem törli a cookie-kat. 4.2.2. Címkék megadása és feladat kiválasztása Egy feladat kiválasztásához a felhasználónak először meg kell adnia azokat a címkéket, amelyekkel a feladat beazonosítható, azaz amelyek legalább részhalmazai a feladathoz tartozó címkehalmaznak. Egy felhasználó csak azon címkékből tud tallózni, amelyek olyan projekt, feladat, csoport, verzió, menedzser vagy egyéb objektumot képviselnek, amihez a felhasználó valamilyen formában köthető (például tagja a projektnek, ő a feladat elvégzésére kijelölt személy, a projekt menedzsere vagy tulajdonosa). Vezető esetén minden címke elérhető. A felhasználóknak egyszerre több címkét is meg kell tudniuk adni ezzel szűkítve az eredményhalmazt. A megjelenített feladatok közül egyszerre csak egy lehet kiválasztva. 4.2.3. Időmérés Az alkalmazással a felhasználóknak képesnek kell lenniük tényleges munkaidejüket rögzíteni egy-egy hozzájuk rendelt feladat kiválasztása után. Egy felhasználó esetében egyszerre csak egy időmérés lehet folyamatban, amelyet ő indít el. Egy mérésnek minden esetben 00:00:00 időponttól kell indulnia és addig tarthat, ameddig a felhasználó manuálisan le nem állítja azt. Tehát az alkalmazás vagy a böngésző program bezárásakor, illetve kijelentkezés esetén is a rögzítés tovább kell, hogy folytatódjon, újbóli bejelentkezéskor a felhasználónak az addig mért időt kell látnia, a rögzítés pedig ekkor is folyamatban kell, hogy legyen. Egy adott mérés szüneteltetése nem lehetséges. 4.2.4. Mért idők listázása A tevékenységekre mért részidőket a felhasználóknak visszamenőlegesen is tudniuk kell listázni (például táblázatszerűen). Minden felhasználó csak a saját időbejegyzéseit láthatja. Egy-egy bejegyzés információt kell, hogy nyújtson a tevékenység megnevezéséről, időpontjáról, időtartamáról. Ezeket a felhasználó módosíthatja,

23

amennyiben a feladat még nem került véglegesen lezárásra. A bejegyzések listája szűrhető kell, hogy legyen a felhasználó által megadott időintervallum vagy címkék alapján. 4.2.5. Jelentés megtekintése A felhasználók számára elérhetővé kell tenni egy a nyilvántartott munkaidejük alapján készült összesítést. A jelentésnek napi részletességgel projektekre és feladatokra lebontva kell mutatnia a rögzített idők összesítését. A projektmenedzserek és vezetők számára ez a tartalom kibővített formában kell, hogy elérhető legyen. A projektvezetőknek képesnek kell lenniük lekérdezni a hozzájuk tartozó projekt résztvevőinek összesített munkaidejét, a cég vezetőinek pedig minden dolgozóét. Továbbá a programnak biztosítania kell olyan kimutatási formát is, amely az egyes felhasználókra vagy projektekre vonatkozóan egyértelmű és aktuális információt hordoz a projekt, valamint az egyes feladatok állapotáról, készültségéről, a feladatokra fordított időről. 4.2.6. Projektek és feladatok létrehozása, menedzselése A vezetői jogkörrel rendelkezők számára az alkalmazásnak biztosítania kell a megrendeléseknek megfelelő projektek és kezdeti feladatok létrehozását valamint ezek szerkesztését. A projektvezetők számára biztosítani kell a projektjeikre vonatkozó menedzsment feladatok elvégzését: feladatok létrehozása, valamint a dolgozók ezekhez való hozzárendelése, a feladatok szerkesztése. A normál felhasználóknak is képesnek kell lenniük feladatok létrehozására. Ezek lehetnek projektekhez kötődő feladatok vagy egyéb projektekhez nem kapcsolható feladatok, mint például oktatáson való részvétel vagy kiküldetés. Ezeket csak a létrehozója szerkesztheti és más dolgozóhoz nem hozzárendelhetőek. 4.2.7. Adminisztrátori funkciók Az adminisztrátori jogkörrel rendelkező feladata a felhasználók hozzáadása, szükség esetén adataik módosítása.

24

5. Tervezés 5.1. Adatbázisterv Az alkalmazás mögött álló adatbázis megtervezése az alkalmazás szempontjából központi szerepet kapó egyedek definiálásával kezdődik. Ezen folyamathoz a követelmény analízisben és a specifikációban megfogalmazottak nyújtanak segítséget. Jól elkülöníthető egyedek a felhasználó (user), a feladat (task), a projekt (project), és a mért idő (time). A meghatározott egyedekhez tartozó tulajdonságok és a fennálló kapcsolatok szemléltetésére ER séma diagramot készítek (5. ábra), aminek segítségével már átláthatóbb az adatbázis struktúrája.

5. ábra - ER diagram

25

Az elméleti megtervezés után előállíthatóak az adatbázis táblái, a táblákban szereplő mezők és a táblák közötti kapcsolatok. (6. ábra)

6. ábra - Relációs adatmodell

Az alkalmazás felépítéséből adódóan a feladatok adatait tartalmazó Task táblának központi szerepe van. Mivel egy feladathoz több címke tartozhat és egy címke több feladatot is kijelölhet, ezért kapcsoló táblára van szükség a címkéket tároló Tag és a Task táblák között. A kapcsoló tábla a kapcsolatot megvalósító idegen kulcsokat tartalmazza. Továbbá kiemelendő, hogy a Tag tábla rendelkezik egy type (típus) mezővel is, amelynek segítségével a címkék majd kategóriákba sorolhatók, így például a projekt címke is kitüntetett szerepet kaphat. Szintén a Task táblához kapcsolódik a Time tábla, amelyben a felhasználók időbejegyzései kerülnek majd eltárolásra. Itt már elegendő egy egyszerűbb egy-több kapcsolat, hiszen egy feladathoz több időbejegyzés tartozhat, de egy időbejegyzéshez

26

mindig csak egy feladat köthető. Ugyanez jellemzi a Time tábla és a felhasználók adatait tartalmazó User tábla kapcsolatát. A User tábla és a szerepköröket tartalmazó Role tábla több-több kapcsolatban állnak, mivel megengedett, hogy egy felhasználó egyszerre több szerepkörrel is rendelkezzen és természetesen egy-egy szerepet többen is birtokolhatnak. Ugyanez érvényes a User és Project tábla kapcsolatára, azaz egy felhasználó tagja lehet több projektnek is és egy projekthez is több felhasználó is tartozhat egyszerre. Megfigyelhető, hogy a Project és User tábla is rendelkezik egy-egy tag_id mezővel. Ezen mezők a Tag tábla id mezőjére hivatkoznak így teremtve kapcsolatot azzal. A logikai kapcsolat 1:1 típusú, azaz egy projekthez vagy felhasználóhoz csak egy címke megnevezés tartozhat. Ezen címkék és a feladatok címkéi között tud majd a felhasználó keresni. 5.2. A felhasználói felület megjelenésének és működésének tervezése Az alkalmazás weboldalainak megtervezésénél fontos szempont volt a hatékonyság és felhasználóbarát viselkedés. Ennek érdekében az egyes oldalak részeit külön modulként kezelem, amelyek az oldal egészétől független életciklussal rendelkeznek, így például külön lehet majd őket betölteni vagy frissíteni. Ez egyrészt növeli a felhasználói élményt, másrészt programozás szempontjából megkönnyíti az egyes modulok újrafelhasználhatóságát. 5.2.1. Menüsáv terve A menüsáv az alkalmazás minden oldalának része, amiből következik, hogy célszerű egy szerkezetileg szülő vagy keret szerepet betöltő template oldalon elhelyezni. A menüsávról érhetőek el az egyes oldalak, valamint az alkalmazásból való kilépést szolgáló gomb. Hat menüpontot tartalmaz: Home, Report, Progress Report, Control, Project Management és Administration. A Home, a Riport és a Progress Riport menüpontok minden felhasználó számára láthatóak, a Control csak vezetői szerepkörrel,

a

Project

Management

projektmenedzseri

szerepkörrel

és

az

27

Administration csak adminisztrációs jogosultsággal rendelkező felhasználók esetén jelenik meg. 5.2.2. Home – Főoldal terve Érvényes bejelentkezést követően minden felhasználó ide kerül átirányításra (7. ábra), mivel minden felhasználó rendelkezik a normál szerepkörrel. Az oldalt négy fő modulra lehet bontani a megfogalmazott követelmények alapján: időmérési modul, feladat kiválasztási modul, a feladat részletei és egy táblázat modul, amelyben a korábban keletkezett részidők jeleníthetőek meg. Időmérési modul Az alkalmazás fő funkcionalitása a különböző projektfeladatokra történő munkaidő rögzítés, amelyet a felhasználó itt kezdeményez, miután kiválasztotta a feladatot. A rögzítés egy Start gomb megnyomásával indul 00:00:00 (óra:perc:másodperc) időponttól, majd valós időben, stopperóra-szerűen folytatódik a manuális leállítás pillanatáig. A Start gomb átváltozik Stop-gombbá jelezve, hogy a felhasználó több rögzítést nem indíthat el egyszerre. Elnavigáláskor, az alkalmazás vagy a böngésző bezárásakor, illetve kijelentkezés esetén is a rögzítés tovább folytatódik, újbóli bejelentkezéskor a felhasználó az addig mért időt fogja látni, a rögzítés pedig ekkor is folyamatban lesz. A rögzítés csak akkor áll le, ha a felhasználó a Stop gombra kattintva leállítja azt. A leállítás eseményt követően új bejegyzés jön létre a főoldalon található időbejegyzéseket tartalmazó táblázatban és a számláló alaphelyzetbe áll. Folyamatban lévő rögzítés esetén a számláló másodpercről másodpercre változik és óra:perc:másodperc alakban mindig az aktuális, elindítástól eltelt időt mutatja.

28

7. ábra – A főoldal terve

Feladat kiválasztási modul Egy feladat kiválasztásához a felhasználónak először meg kell adnia a kívánt címkéket (Labels), amelyet követően az erre illeszkedő feladatok listája elérhetővé válik. A címkéket egy címkehalmazból kiválasztva lehet megadni. A korábban megfogalmazott követelmények szerint csak azon címkék láthatóak egy felhasználó számára, amelyekhez tartozó projekt, feladat vagy egyéb csoport kötődik hozzá, tehát a felhasználó címkéje szerepel az adott elem címkehalmazában. Egyszerre több címke is megadható csökkentve ezzel az eredmény halmazt. Kiválasztott feladat részletei A feladat kiválasztását követően annak adatai (neve, állapota, prioritása, elkészültségét jelző százalék, címkéi) megjelennek. Láthatóvá válik a feladat rövid leírása, valamint a felhasználók megjegyzéseket tehetnek, amelyek eltárolódnak az adatbázisban. A főoldalon csak az utolsó két hozzászólás jelenik meg, de a felhasználó a More gombra

29

kattintva megnyithatja az összes korábbi megjegyzést, amelyek egy felugró ablakban jelennek meg. A szerkesztés funkció csak azon felhasználó számára érhető el, aki a feladatot létrehozta vagy az adott projektnek a vezetője. A szerkesztés gombra kattintva megjelenik egy felugró ablak, amelyben a kiválasztott feladat adatai szerepelnek. Táblázat modul Az

oldal

alján

megjelenő

táblázatban

kapnak

majd

helyet

a

megadott

időintervallumban a felhasználó által rögzítésre került munkaidők. A táblázat egy sorát kiválasztva az egyes bejegyzések szerkeszthetővé válnak. A táblázathoz új sor is hozzáadható egy korábbi időpontra vonatkozóan a „+” gombra kattintva, amely egy felugró ablakot nyit meg, illetve sorok el is távolíthatóak. A táblázat tartalma dinamikusan változik, azaz ha a felhasználó leállít egy mérést vagy hozzáad a táblázathoz egy bejegyzést, az azonnal megjelenik új sorként. 5.2.3. Report – Összesítő oldal terve A felhasználó az összesítés - Report oldalon tudja majd megtekinteni rögzített munkaidőinek összesített kivonatát (8. ábra). Ehhez először ki kell választania a kívánt projektet, valamint opcionálisan tovább is lehet szűkíteni az eredményt címkék megadásával. A megjelenítés táblázatos formában, napi részletességgel a kiválasztott projektre és annak feladatai szerinti lebontásban történik meg. A megjelenített eredmény tovább szűkíthető kezdő és záró dátumokkal így csak azok a tevékenységek kerülnek összesítésre, amelyek ezen intervallumban jöttek létre. Projektmenedzseri és vezetői jogosultság esetén az oldal megjelenése kiegészül egy legördülő listával, amelyben kiválasztható azon személyek összesítő táblázata, amelyek megtekintésére az adott lekérdezőnek jogosultsága van. Vezető esetén ez bármely felhasználó, projektmenedzser esetén pedig az irányított projektek tagjai.

30

8. ábra - Report oldal terve

5.2.4. Control – Vezetői oldal terve A vezetők számára a Control oldalon (9. ábra) lehetséges a projektek létrehozása és szerkesztése, valamint az egyes projektekhez feladatokat és résztvevőket adhatnak hozzá.

9. ábra - Control oldal terve

31

5.2.5. Progress Report oldal terve

10. ábra - Progress Report oldal teve

A projekt kiválasztása után megjelenik a kiválasztott projekthez tartozó összes feladat és annak a 10. ábrán látható összes jellemzője táblázatos formában címkék szerint csoportosítva. A jelentés alapján ellenőrizhető az adott feladat teljesítettsége, és hogy a megbecsült feladat-időből már mennyi fogyott el. További címkéket megadva az eredmény szűkíthető. 5.2.6. Project Management oldal terve Ezen az oldalon hajthatóak végre a projekttel kapcsolatos menedzsment feladatok, mint például új feladatok hozzáadása, meglévők szerkesztése és dolgozók hozzárendelése a feladatokhoz. 5.2.7. Administration oldal terve Csak az adminisztrátor szintű felhasználók számára elérhető felület. Ezen az oldalon végezhető el a felhasználók hozzáadása, adataik módosítása és szerepkörökhöz való hozzárendelése.

32

11. ábra – Administration oldal terve

5.3. A modell réteg osztályainak terve Az alkalmazás logikáját megvalósító modell rétegnek alapvetően követnie kell a korábban meghatározott főbb objektumokat és az adatbázisban kialakított struktúrát. Ezek alapján hat fő modell osztály különíthető el (12. ábra). Adattagjaik megfelelnek az adatbázis tervezés során meghatározott táblák mezőinek.

12. ábra - A főbb modell osztályok terve

Az alaposztályokon kívül szükség lesz úgynevezett ViewModel osztályokra is, amelyek a megjelenítés során kerülnek felhasználásra. Szerepük az, hogy a megjelenítési és a kontroller rétegek között adattároló objektumként szolgáljanak. Itt kerülnek majd definiálásra többek között a különböző listák elemei vagy az egyes azonosítóknak megfelelő, de könnyebben értelmezhető és kezelhető nevek.

33

A program az adatbázissal való kapcsolat kiépítéséhez és az adatok eléréséhez Entity Framework keretrendszert fog használni, amely nagyban megkönnyíti az adatbázissal történő munkát. Segítségével a lekérdezéseket SQL nyelv helyett LINQ kifejezésekkel is meg lehet valósítani, az ezeket tartalmazó osztály szintén a modell rétegen belül kap majd helyet. 5.4. A kontroller réteg osztályainak terve A kontroller réteg egyik fő feladata a megjelenítési réteg kiszolgálása, ezért az alaposztályok az alkalmazás weboldalai szerint körvonalazódnak (13. ábra). Az egyes metódusok a korábban felvázolt modulok szerinti rendszert követik. A Page-re végződő metódusok csak egy-egy oldal vázát adják vissza, a tényleges tartalom kitöltéséért a Module-ra végződő metódusok felelnek, ezek PartialView típusú template fájlokat jelenítenek meg. A harmadik csoportja a kontroller osztályok metódusainak az adatok definiálásáért és manipulációjáért felel, amelyek nagy része az osztálytervben még nem szerepel.

13. ábra - A főbb kontroller osztályok terve

34

6. Implementálás 6.1. Az implementáláshoz használt szoftverek Az implementálás Microsoft Visual Studio 2013 fejlesztői környezetben történt az ASP.NET MVC 5 keretrendszert használva C# nyelven. A fejlesztés során a szerver oldali kód hibáinak felderítésére és javítására a Visual Studio-ba beépített debugger-t és a Log4NET könyvtárat használtam, amely segítségével könnyen megvalósítható a futásidejű események és hibák naplózása. A kliens oldali JavaScript kód hibáinak megtalálására a Google Chrome webböngésző fejlesztői eszköze nyújtott segítséget, amely egyben remek megoldás a CSS formázási szabályok azonnali kipróbálásához is. Az adatbázis tárolásához Microsoft SQL Server 2014-et használtam, a táblák létrehozása és kezelése pedig SQL Management Studio-val történt. Az alkalmazás Entity Framework 6 (továbbiakban EF) adatelérési keretrendszerrel valósítja meg az adatbázis elérését, az abból történő lekérdezést és az adatok módosítását. Az EF entitásokat hoz létre, amelyek a relációs adatokat reprezentálják és a közöttük lévő kapcsolatokat is automatikusan kiépíti (ez az ún. objektum-relációs leképzés vagy ORM). Az EF rendkívül rugalmas rendszer, az adatok és az objektumok közötti kötés többféleképpen is megvalósítható általa. A relációs adatok elérését pedig LINQ (Language-Integrated Query) kifejezéseken keresztül is lehetővé teszi, illetve ezen kifejezéseket fordítja át SQL nyelvre a háttérben. 6.2. Adatkezelés Az adatkezelés során az Entity Framework database first („adatbázis először”) módszerét használtam, ami azt jelenti, hogy az adatbázist és annak tábláit, az azok közötti kapcsolatokat már előre definiáltam a megtervezett relációs adatmodell szerint. Az EF ehhez a kész struktúrához kapcsolódik a megadott csatlakozási paraméterek alapján, és ennek megfelelően hozza létre az entitásokat (14. ábra), valamint azok kapcsolatait. Ennek következménye, hogy a teljes modell készlet előállt a táblákban definiált mezőknek és azok típusainak megfelelő tulajdonságokkal.

35

14. ábra - A generált modell osztályok

Mivel generált osztályokról van szó az ezekben történő módosítás egy frissítés hatására elveszne. Ahhoz, hogy meta adatokat, a szükséges helyeken új tulajdonságokat és validációs szabályokat tudjak ezekhez az osztályokhoz kapcsolni, parciális osztályokat hoztam létre, ezek a már korábban említett ViewModellek. Ezen osztályok tartalmazzák a megjelenítéshez szükséges logikát, valamint tükrözik az alkalmazás

egy-egy

folyamatának

állapotát.

Segítségükkel

könnyebben

megvalósítható a model binding (adatkötés), mint csak az EF által létrehozott osztályok használata esetén, mivel itt a megjelenítésnél alkalmazott összetettebb elemeknek megfelelő objektumjellemzők is megadhatók. Például címkéket tartalmazó legördülő lista elemei közül a kiválasztott címkék azonosítóinak automatikus kötése is előkészíthető könnyen, míg a Tag osztályt nem lehet módosítani ennek megfelelően és a kiválasztott címkéket csak „manuális” úton a kérés objektumból vagy az URL-ből lehetne kiszedni. A model binding technika lényege, hogy a kontroller és a megjelenítési réteg közötti oda-vissza kommunikáció során a ModelBinder példányosítja a ViewModel osztályokat és az adatokat az objektumok tulajdonságaihoz köti, így egy tisztább, rövidebb és hatékonyabb kódot kapunk. Nem áll fenn az a veszély sem, hogy egy-egy hibás vagy időközben megváltoztatott manuális kötés vagy kérésből történő adatkiolvasás hibája futásidőben következik be. Ezen kívül, ahogy a tervezésben szerepelt, szükség volt egy szintén parciális saját kontextus modell osztályra, amelyben a LINQ lekérdezéseket és lambda kifejezéseket tartalmazó metódusokat helyeztem el (MyDBModelContext.cs), így az eredmények egyenesen az üzleti objektumokba érkeznek (Project, Task, User, Role, Tag, Time, Comment). A lambda kifejezések és a LINQ query-k között csak formai különbség van, fordítás során a LINQ lekérdezések is lambda kifejezésekké konvertálódnak.

36

Az EF által létrehozott struktúra a 15. ábrán szerepel. Megfigyelhető, hogy a több-több kapcsolatot megvalósító kapcsolótáblák alapján nem jött létre entitás, mivel ebben a táblában az idegen kulcsokon kívül nincs más mező, de természetesen a kapcsolat fennáll generikus konténerek segítségével (Navigation Properties). A LINQ lekérdezések esetén is ezek segítségével teremthető kapcsolat két entitás között.

15. ábra - Az Entity Framework által létrehozott entitások

37

6.3. Autentikáció és autorizáció Az alkalmazás form alapú hitelesítést használ, azaz a felhasználó egy bejelentkezési űrlapot nevével és jelszavával kitöltve lép be, amely adatok helyessége a szerveren kerül ellenőrzésre. Az MVC rendszer alapértelmezetten tartalmaz hitelesítési és szerepkör ellenőrzési funkciót, azonban én felüldefiniáltam ezeket az alkalmazás saját igényei szerint. A hitelesítési folyamat működésének vázlata az alábbi folyamatábrán látható. alidateUser

Login Form Username: Password:

1.

System.Web.Security.Membership public static bool ValidateUser ( string username, string password )

3.

MembershipProvider CustomMembershipProvider

2. Web.Config <membership defaultProvider="CustomMembershipProvider"> <providers>

Első lépésben a megadott név és jelszó elküldésre kerül a szervernek, ahol meghívódik a validációt végző Membership keretrendszerbeli osztály, ami az alkalmazás Web.config konfigurációs fájlja alapján dönti el, hogy melyik hitelesítő osztályt használja a validáláshoz. Jelen esetben ez a CustomMembershipProvider osztály, ami a MembershipProvider absztrakt osztályt valósítja meg. Szerepe az ASP.NET és az adatbázis közötti felület kialakítása. Itt kerül definiálásra az alkalmazás speciális hitelesítési logikája a felüldefiniált ValidateUser metódusban, ami az adatbázisban ellenőrzi az adatokat. A validáláson kívül GetUser metódusával visszaadja az aktuális felhasználó adatainak objektumát. Ezen objektum a MembershipUser osztályból származtatott CustomMembershipUser osztály példánya. Az adatok között szerepel a felhasználó neve és jogosultsági köre vagy körei.

38

Az autorizáció hasonlóképpen működik: alidateUser

[Authorize(Roles = "admin")]

1.

System.Web.Security.Roles public override string[] GetRolesForUser( string username )

2. 3. Web.Config <providers>

RoleProvider CustomRoleProvider

Bármely kontroller osztály azon metódusa, amelyre az Authorize attribútum alkalmazva van csak azon felhasználó számára érhető el, aki bejelentkezett és rendelkezik a megadott jogosultsággal. Ez a Roles osztály meghívásával kerül ellenőrzésre, amely szintén a konfigurációs fájlban megadott RoleProvider-re támaszkodik. További két osztályra is szükség van az autorizáció működéséhez. Egyik az IIdentity interfészt implementáló CustomIdentity, amely a felhasználó adatait tárolja, az azokhoz való hozzáférést biztosítja és a másik az IPrincipal interfészt megvalósító CustomPrincipal, ami pedig a felhasználó jogosultságáról szolgáltat információt.

16. ábra – Az autentikációt és autorizációt végző osztályok

39

6.4. Adatellenőrzés Azon folyamatokhoz, amelyekhez a felhasználótól való adatbekérés szükséges (mint például létrehozás vagy szerkesztés) szükséges a kliens oldali validáción túl szerver oldali ellenőrzés kapcsolása is. Erre azért van szükség, mert kliens oldalon a JavaScript kód könnyen módosítható vagy akár teljesen ki is kapcsolható. A megvalósítás egyik módja az lenne, hogy minden szükséges helyen validációs attribútumokat helyeznék el, ugyanakkor létezik egy ettől egyszerűbb univerzális módszer, a .NET-hez készült FluentValidation validációs könyvtár, amely lehetővé teszi egyedi logikát tartalmazó validációs osztályok egyszerű létrehozását. Az egyes szabályok a validációs osztályok konstruktoraiban kerülnek elhelyezésre. Ilyen például a kötelezőségre, számosságra vagy valamilyen összetettebb szabályra történő illeszkedés. A bonyolultabb szabályok, amelyeket nem lehet tisztán lambda kifejezésekkel leírni, külön metódusokban kerülnek megvalósításra. Egy szabály nem teljesülése esetén egyedi hibaüzenet is megjeleníthető a view-ban. Részlet a projekt modell validációjából: public ProjectValidator() { RuleFor(model => model.name).NotEmpty().WithMessage("*"); RuleFor(model => model.manager_id).NotEmpty().WithMessage("*"); RuleFor(model => model.name).Must(CheckProjectNameUniqueness) .WithMessage("Project already exists!"); RuleFor(model => model.tag_name).NotEmpty().WithMessage("*") .Must(CheckTagNameUniqueness) .When(model => !String.IsNullOrEmpty(model.tag_name)) .WithMessage("Tag name is not unique!"); } private bool CheckProjectNameUniqueness(String projectName) { Project testProject = dbEntity.GetProject(projectName); if (testProject != null) { return false; } return true; }

Az ellenőrzés a kívánt modell osztály definícióján elhelyezett attribútummal hívható meg. Az előző ProjectValidator szabályai érvényesíthetőek „manuálisan” az osztály példányosításával és a Validate metódus meghívásával vagy a modell osztályon elhelyezett attribútummal is: [FluentValidation.Attributes.Validator(typeof(ProjectValidator))]

40

Az alábbi ábrán a validációs osztályok osztálydiagramja látható:

17. ábra - Az adatvalidációért felelős osztályok

6.5. Címkék megadása, feladat kiválasztása Az egyes oldalak betöltése során a View-ból Html.Action metódusokkal meghívásra kerülnek egy-egy modult betöltő kontroller metódusok is. Egy ilyen hívás eredményeként jelenik meg a címkék kiválasztásához szükséges legördülő listát tartalmazó oldalrészlet, többek között a Home oldalon is. A választható címke elemek halmazát két lépés eredménye adja. Elsőként a felhasználó neve alapján (amelyet a CustomIdentity szolgáltat) lekérdezésre kerülnek a felhasználó adatai, ebből a felhasználó saját címkéjét reprezentáló azonosító szükséges (tag_id). A második lépésben több LINQ lekérdezés kerül végrehajtásra: lekérdezésre kerülnek azon feladatok, amelyek címkéi között szerepel az adott tag_id, majd ezután feltöltésre kerül egy lista a lekért feladatok összes címkéivel. Végezetül megjelenítésre kerül a modul rajta a feltöltött címkelistával. A megjelenítést egy MagicSuggest elnevezésű jQuery legördülő lista végzi, amely lehetővé teszi egyszerre több elem kiválasztását úgy, hogy azok ténylegesen címke-szerűen kerülnek megjelenítésre. Amint kiválasztásra kerül egy címke egy AJAX kérés küldődik a szerver felé a már kiválasztásra került címkék azonosítóival, amelyek alapján meghatározásra kerül a megjelenítendő feladatlista. Ez szintén külön modulként kerül betöltésre. Egy feladat kiválasztása után – egy újabb AJAX kérésre – betöltődik a feladat adatait tartalmazó modul is. A folyamat eredménye a 18. ábrán látható. 41

6.6. Az időmérés folyamata Az időmérés folyamatát a felhasználók a Home oldalon tudják elindítani a Start gomb megnyomásával. Ehhez először szükséges egy feladat kiválasztása, amely az előző pontban leírt folyamat szerint megy végbe, és aminek megtörténte kliens és szerver oldalon is ellenőrzésre kerül. Sikeres indítás során AJAX-szal meghívódik a HomeController TimeTracking metódusa a kiválasztott feladat azonosítójával, amely JSON formátumban kerül a POST típusú kérésbe. A TimeTracking metódus szerepe kettős, mivel a mérés leállításáért és elindításáért is felelős. Működése során elsőként az adatbázisból lekérésre kerül az adott felhasználó legutolsó azon időbejegyzése, ahol a stop mező üres. Ez legfeljebb csak egyetlen rekord lehet. Ha van ilyen, az jelzi, hogy egy időmérés folyamatban van, így a leállítási ág fog érvényesülni, amelyben a lekért Time entitás stop tulajdonsága beállításra kerül az adott dátum és időpillanatra (DateTime.Now). Ha nincs folyamatban lévő időmérés, akkor a metódus példányosítja a Time osztályt, majd a létrejött objektum tulajdonságainak beállítja a megfelelő értékeket: az adott dátum és időpillanat értékét, a felhasználó és a feladat azonosítóit. Végezetül a módosult vagy újonnan létrejött entitás elmentésre kerül az adatbázisban. A kliensnek küldött válaszüzenet hiba esetén figyelmeztető üzenetet tartalmaz, egyébként pedig a sikerességet jelző változót. A főoldalon látható jQuery stopperóra az elindítási vagy leállítási esemény szerint elindul vagy megáll és lenullázódik. Továbbá mindkét esemény kiváltja az oldal alsó részén elhelyezkedő tábla frissítését. A kiválasztott feladatot és az elindult mérési folyamat eredményét a 18. ábra szemlélteti. Az, hogy egy adott felhasználó esetén folyamatban van-e rögzítés, minden bejelentkezésnél, illetve Home oldal betöltésnél ellenőrzésre kerül a Time táblában. Ha van „befejezetlen” rekord, akkor a start idő alapján kiszámításra kerül az időkülönbség, majd ez visszaadódik a kliensnek, ahol az ezért felelős jQuery függvény ennek megfelelően elindítja a stoppert. A felhasználó így egy folyamatos időmérést tapasztal, de gyakorlatilag ez csak két időpillanat különbségének az eredménye. 42

18. ábra – Időmérés egy kiválasztott feladatra

6.7. Kimutatás megjelenítése Az egyes feladatok állapotairól készült kimutatást a felhasználók a Progress Report oldalon tekinthetik meg. Ennek betöltése a feladathalmazt kijelölő címkék megadásával lehetséges, amely folyamat a 6.5. pontban leírtak alapján megy végbe azzal a különbséggel, hogy ezen az oldalon a projektmenedzserek a projektjeikhez tartozó feladatok címkéi közül tudnak választani, míg vezető szerepkörrel rendelkező felhasználók esetén minden címke elérhető. Egy-egy címkekiválasztás esemény hatására meghívódik a ProgressReport kontroller megfelelő metódusa, amely visszaad minden fontos információt a feladatokról. A feladatok alapadatain kívül előállít származtatott adatokat is, ezek az adott feladatot birtokló felhasználók és a feladathoz tartozó címkék listája, valamint az összes idő, amit eddig a feladatra mértek. Továbbá a megadott címkék közül csoportosítást végez a feladatokra nézve azokkal, amelyek csoportosító típusúak, mint például alprojektek, verziók vagy egyéb csoportosítási

43

céllal hozzárendelt címkék. Az eredmény táblázatos formában kerül megjelenítésre, amelynek egy példája a 19. ábrán látható.

19. ábra - Progress Report

Megfigyelhető, hogy az első négy feladathoz tartozik egy test_sub_group nevű címke is, amely csoportosító típusú, ezért ennek megfelelően készült egy összesítő sor. Segítségével az egyes feladatok állapota mellett könnyen megállapítható a teljes feladatcsoport jelenlegi állapota is. Ha a felhasználó egy csoport nevére kattint, megjelenik egy kördiagram, amely a feladatokra mért idők összegzését szemlélteti (20. ábra).

20. ábra - Összegző kördiagram

44

7. Összefoglalás és jövőkép Szakdolgozatom elkészítése során elsődleges célom az volt, hogy egy működőképes munkaidő- és tevékenység-nyilvántartó webalkalmazást hozzak létre, amely a DACHS Hungary Kft. dolgozóinak munkáját a munkaidő-nyilvántartás vezetés szempontjából megkönnyíti. Úgy gondolom, hogy célomat sikerült véghezvinni, az elkészült program a megfogalmazott követelményeknek eleget tesz. A címkézési módszer megfelelőnek látszik a régebbi, hierarchikus szemléletű és kissé már elavult rendszer kiváltására, továbbá az alkalmazott ASP.NET MVC keretrendszer biztosítja az esetleges jövőbeni továbbfejlesztések gyors és hatékony megvalósítását. A program megfelelő alapot nyújt a közeljövőben bekövetkező használatba vételhez, ugyanakkor ennek kivitelezése előtt még meg kell felelnie a cég elvárásainak és szabályainak a biztonságra, valamint a DACHS többi rendszerével történő összekapcsolásra vonatkozóan. További célom volt a szakdolgozattal, illetve a készülő programmal az is, hogy megismerkedjek az ASP.NET MVC keretrendszerrel és korábbi tanulmányaim során a web technológiákról szerzett ismereteimet bővítsem. Úgy érzem, hogy ezt a célomat is sikerült elérnem és a dolgozat, valamint a program elkészítésével biztos alapot és kellő rutint szereztem ahhoz, hogy tudásomat a jövőben kamatoztatni tudjam munkám és további tanulmányaim során.

45

8. Summary The main aim of my thesis is to present the software development process of a functioning time and task management web application which purpose is to make the everyday time and task tracking easier for the people of DACHS Hungary Kft. during their work by replacing an old application. I think, I successfully accomplished the project, the finished application meet all the requirements. The newly introduced tagging system is capable to replace the hierarchical principle. Furthermore the applied ASP.NET MVC framework will make the further development and maintains more efficient in the future. My application’s current state provides a proper base for putting it in practice in the near future, however it has to meet all the security and integration rules of the company before this action. My further aim with the thesis was to improve my knowledge of web technologies by learning the ASP.NET MVC framework. I think, I successfully achieved this goal too and I acquired the basics of the framework. I am sure, that I will be able to capitalize this knowledge in my future work and studies.

46

9. Irodalomjegyzék Regius Kornél: ASP.NET MVC 4+, elektronikus kiadás Adam Freeman: Pro ASP.NET MVC 4 4th Edition, Apress, 2012 Brian Driscoll, Nitin Gupta, Robert Vettor, Zeeshan Hirani, Larry Tenny: Entity Framework 6 Recipes, Apress, 2013 Jon Galloway, Brad Wilson, K. Scott Allen, David Matson: Professional ASP.NET MVC 5, Wrox Press, 2014

47

10. Melléklet A DVD tartalma: Munkaidő- és tevékenység-nyilvántartó webalkalmazás fejlesztése jegyzék: 1. Forráskód jegyzék, amely a program forráskódját tartalmazza 2. Adatbázis jegyzék, amely az adatbázis fájlt tartalmazza 3. Összefoglalás docx-file 4. Summary docx-file 5. Szakdolgozat kiírás docx-file 6. Munkaidő- és tevékenység-nyilvántartó webalkalmazás fejlesztése docx-file 7. Munkaidő- és tevékenység-nyilvántartó webalkalmazás fejlesztése pdf-file

48