Kérdőív kezelő modul fejlesztése információs rendszerben Szakdolgozat

Miskolci Egyetem Gépészmérnöki és Informatikai Kar Általános Informatikai Tanszék

Kérdőív kezelő modul fejlesztése információs rendszerben Szakdolgozat

Készítette: Név: Misztina Péter Neptunkód: NMDG1P Szak: Mérnök Informatikus Bsc

Misztina Péter

Kérdőív kezelő modul fejlesztése információs rendszerben

TARTALOMJEGYZÉK 1

Bevezetés.................................................................................................................................... 1 1.1

2

Vállalat bemutatása ............................................................................................................ 3

Vízió ........................................................................................................................................... 5 A beágyazó rendszer ismertetése ............................................................................... 5 Probléma megfogalmazása ......................................................................................... 6 Felhasználói környezet ............................................................................................... 7 A termék használatának előnyei ................................................................................. 7

3

Felhasználandó technológiák, kutatás ........................................................................................ 9 ASP .NET MVC....................................................................................................... 10 Repository Pattern .................................................................................................... 13 iTextSharp ................................................................................................................ 14

4

Funkcionális követelmények .................................................................................................... 17 4.1

Általános követelmények ................................................................................................. 17

4.2

Use Case diagram ............................................................................................................. 17 Fogalma .................................................................................................................... 17 A modul használati esetei ......................................................................................... 18 Különböző használati esetek kifejtése ...................................................................... 18

5

Rendszerterv ............................................................................................................................. 24 5.1

ER diagram....................................................................................................................... 24 Fogalma .................................................................................................................... 24 Kérdőív kezelő modul ER diagrammjai ................................................................... 24

5.2

Relációs adatmodell ......................................................................................................... 26 Fogalma .................................................................................................................... 26 Kérdőív Kezelő Modul Relációs Modell.................................................................. 27

5.3 6

Felület tervek .................................................................................................................... 28

Proof of Concept ...................................................................................................................... 33 6.1

Bevezetés.......................................................................................................................... 33

6.2

Fejlesztés .......................................................................................................................... 33 Repository Pattern használata .................................................................................. 34 iTextSharp használata a POC-ban ............................................................................ 36 Felületek megvalósítása ........................................................................................... 37 Responsive design .................................................................................................... 42

7

Összefoglalás............................................................................................................................ 44 7.1

Továbbfejlesztési lehetőségek .......................................................................................... 45 Levélküldés .............................................................................................................. 45 I

Misztina Péter


Értékelések összegzése ............................................................................................. 45 8

Summary .................................................................................................................................. 47 8.1

Possible future development ............................................................................................ 48 Mailing module ........................................................................................................ 48 Charts ....................................................................................................................... 48

9 10

Irodalomjegyzék ....................................................................................................................... 49 Ábrajegyzék ......................................................................................................................... 50

II

Misztina Péter


1 BEVEZETÉS A szakdolgozatom témáját képező feladatot az Abesse Zrt-től kaptam, ahol szoftverfejlesztő gyakornokként dolgozom. A cég elvállalta egy intranetes vállalatirányítási rendszer kifejlesztését. Ennek az egyik modulja egy kérdőívkezelő rendszer. Szakdolgozatomban ennek a modulnak a kifejlesztésével foglalkozom. A kérdőíves adatgyűjtés, mint módszer, minden vállalat számára hasznos lehet, hiszen például a dolgozói elégedettségről vagy a vállalat működéséről ezzel a technikával lehet legegyszerűbben és legmegbízhatóbban ismereteket szerezni. De jól használható ez a módszer külső értékelések elkészítésére is. A megbízó cég számára fontos, hogy vállalatirányítási rendszerükbe integráljanak egy kérdőívkezelő modult, hiszen így strukturáltan tudják begyűjteni, rendszerezni és archiválni a kérdőíveket. A jelenlegi rendszerükben nem található ilyen funkció, emiatt külön erőforrást és energiát igényel az űrlapok karbantartása, begyűjtése. A visszakereshetőség sem túl ideális, a keresés papír alapon tárolt dokumentumok esetén hosszadalmas folyamat és sokszor nem vezet eredményre. Arról nem is beszélve, hogy külön raktárt kell fenntartani erre a célra, különben fontos iratok veszhetnek el. Vannak olyan kérdőívek, melyeket jelenleg elektronikus úton küldenek ki és kérnek be, de ezeket sem tárolják külön rendszerben. Ez szintén nem hatékony megoldás, mert nehezen tartható nyilván, hogy kik küldték már vissza az értékeléseket és kik nem. Ezen kívül szükség van egy operátorra, aki elhelyezi a beküldött fájlokat a megfelelő helyre. Ennek a módszereknek a tökéletesítése a rendszer jelenlegi működési formájában lehetetlen feladatnak tűnik. Az új modul megoldást nyújt ezekre a problémákra azáltal, hogy saját menedzsment felületet tartalmaz, ahol nyomon lehet követni a kérdőíveket. Egységes felületet biztosít az értékelések kitöltésére és a kiküldött fájlok feltöltésére. Az adatok tárolása és visszakereshetősége is jelentősen egyszerűsödik a modul használatával. A szakdolgozat tíz fejezetre oszlik, melyek a következő módon épülnek fel. 

Első fejezet: Ebben a fejezetben mutatom be a vállalatot.



Második fejezet: A fejezet célja a probléma bemutatása és egy vízió elkészítése.

1

Misztina Péter




Harmadik fejezet: Itt található a felhasznált technológiák ismertetése, működésük ismertetése.



Negyedik fejezet: A negyedik fejezetben a rendszerrel szemben támasztott követelményekről és specifikációról van szó.



Ötödik fejezet: A rendszer konkrét megvalósítási tervezetét tartalmazza.



Hatodik fejezet: Ebben a fejezetben kerül sor a rendszer konkrét megvalósításának tárgyalására, mely tartalmazza a felhasznált technológiák ismertetését is.



Hetedik fejezet: Az összegzés és a tovább fejlesztési lehetőségek leírása olvasható ebben a részben.



Nyolcadik fejezet: A dolgozat angol nyelvű összefoglalója.



Kilencedik fejezet: Felhasznált irodalmak jegyzéke.



Tízedik fejezet: Ábrajegyzék.

2

Misztina Péter


1.1 VÁLLALAT BEMUTATÁSA A vállalat neve: Abesse Informatikai Tanácsadó Zrt. Rövid bemutatás: Az Abesse Informatikai Tanácsadó Zrt-t 2003-ban alapították ambiciózus informatikai szakemberek azzal a céllal, hogy nagyvállalatok számára egyszerű, stabil, rugalmas megoldásokat kínáljanak a folyamatinformatika területén. A cég fő erőssége a “technológiafüggő tanácsadás” Microsoft alapú rendszerekre. Az Abesse hat év óta viseli a Microsoft kitüntető címét, az „Év legkompetensebb partnerei”-t, ami tagadhatatlanul a cég munkájának objektív elismerése. Az Abesse alapvető elvei az ügyfelekkel kapcsolatban: 

„a lehető legkisebb átfutási idővel tudják kiszolgálni vevőiket,



a lehető legjobb együttműködést biztosítsák a munkatársak és a szervezeti egységek közt,



a lehető legkevesebb erőforrással és költséggel működjenek,



a lehető legszorosabban integrálhassák meglévő rendszereit,



a lehető legjobb megfelelése legyen az aktuális szabályozóknak,



a vezetők a lehető legpontosabb képpel rendelkezzenek a cég működéséről,



és mindez a lehető legnagyobb stratégiai mozgásteret biztosítsa a cégnek, ha a piaci viszonyok szükségessé teszik a változást.”

Alapvető cégadatok: Név Székhely Főbb tevékenységek

Abesse Informatikai Tanácsadó Zártkörűen Működő Részvénytársaság 1119 Budapest, Boglárka utca 32. Informatikai szaktanácsadás, szoftver-szaktanácsadás és szoftverkészítés

Telefon

+36 1 203-5631

E-mail

http://www.abesse.hu/abesse/kapcsolat

3

Misztina Péter

Honlap


http://www.abesse.hu

Az Abesse név az alábbi latin közmondásból származik, mely közmondás egyben kifejezi a cég filozófiáját is: „Ab esse ad posse”: A létezőből kiindulva eljuthatunk a lehetségeshez Az Abesséről bővebben az [1]-es linken olvashatunk.

4

Misztina Péter


2 VÍZIÓ A beágyazó rendszer ismertetése Az általam készítendő kérdőívkezelő modul egy egyedi fejlesztésű, webes, intraneten üzemelő rendszerben kerül elhelyezésre. A Megrendelő által jelenleg használt rendszert kell kiváltani, egy O365-be integrált alkalmazással. (A hivatalos O365 weboldal a [19]-es linken található.) A rendszer fejlesztésének elsődleges oka az, hogy a jelenlegi intranetes alkalmazás a cég fejlődésének és bővülésének köszönhetően már nem elégíti ki a Megrendelő igényeit. A feladat tehát egy olyan projekt-kontrolling rendszer kialakítása, amely a mostanit messze meghaladja mind funkcióit, mind használhatóságát tekintve. A rendszerrel szemben alapvető elvárás a modern alkalmazásfejlesztési technológiák használata. A rendszer a következő fő modulokat fogja tartalmazni: 

Alkalmazottak, megbízók, alvállalkozók nyilvántartása



Szerződések, megbízások, kötelezettségek kezelése



Számlázás támogatása



A projekt menedzsment hatékonnyá tétele

Az elkészülő rendszer részben Sharepoint Online funkciókat használ, kiegészítve, bővítve azokat. A projektek, számlák, illetve a dolgozók adatait a rendszer egyedi adatbázisban tárolja. Az intranetes funkciók elérésére a jelenlegihez hasonlóan egy egyedi fejlesztésű alkalmazás kerül kialakításra. A futó projektek támogatására készített Sharepoint webhelyek mellett lesz elérhető a főként projektkontrolling funkciókat megvalósító intranet alkalmazás. A rendszerbe történő bejelentkezés Sharepointon keresztül valósul meg, így a felhasználóknak nem kell újra bejelentkezni az oldalra navigálás során.

1. Beágyazó rendszer felépítése 5

Misztina Péter


Az alkalmazás integráltan egészíti ki a Megrendelő O365 Sharepoint platformját az egyedi fejlesztésű komponensekkel, egységet alkotva azzal, mint ahogy ez az 1-es ábrán látható. A fejlesztendő rendszerrel szemben általános elvárás, hogy az egyes funkciók módosítása, illetve további funkciók beépítése a kód kevés részének változtatását igényelje. Probléma megfogalmazása A modul kifejlesztését elsősorban az indokolja, hogy a jelenlegi rendszer nem tartalmaz olyan funkciót, mely megoldaná, vagy legalább segítené a kérdőív-kezelés problémakörét. Emiatt merült fel az igény a szakdolgozatom lényegét képező modul kifejlesztésére. Jelenleg három féle kérdőívet használnak a cégnél. 

Dolgozói értékelés,



megbízói értékelő lap és



alvállalkozói kérdőív.

Ezeknek a begyűjtése különböző módon történik. A dolgozói értékelés esetén papír alapon kerülnek begyűjtésre a lapok és kézzel dolgozzák fel őket. A másik két esetben elektronikus módon fogadják a kérdőíveket. Ugyanakkor nincs semmilyen feldolgozó informatikai rendszer, ami támogatná ezt a tevékenységet. Indokolt tehát, hogy a feladatok megkönnyítése és a munka hatékonyabbá tétele érdekében az új intranetes rendszerbe egy olyan modult építsünk, mely támogatja ezt a folyamatot. Jelen modul kifejlesztése elsősorban a megbízókat, a projektvezetőket, a csoportvezetőket és a dolgozókat érinti. Az ő munkájukat könnyíti meg és egyszerűsíti majd ez a megoldás. Emellett jelentős költségmegtakarítással is számolni lehet, hiszen gyakorlatilag nem kell időt fordítani a kérdőívek begyűjtésére és feldolgozására. További előny a dolgozók és a megbízók szempontjából, hogy a leadás menete is leegyszerűsödik: néhány kattintással a feladat elvégezhető. Az adattárolás szempontjából is hasznos a modul elkészítése, mert segítségével visszamenőleg is könnyen előkereshetőek lesznek a kérdőívek adatai, így a papíralapú tárolás feleslegessé válik.

6

Misztina Péter


Érintettek és felhasználók: 

Dolgozók: Alapvető jogosultságokkal rendelkező személyek. Feladatuk csak annyiból áll, hogy a megfelelő időszakban kitöltik az űrlapot.



Csoportvezetők: A dolgozói értékelések összegzését a csoportvezetők kapják meg, kiértékelt formában.



Projektvezetők: Az alvállalkozói kérdőív kitöltése a feladatuk; egy projektet csak úgy lehet lezárni, ha van hozzá értékelés.



Megbízók: A számukra kiküldött kérdőívet, amely a rendszert működtető vállalat munkásságát értékeli, a kitöltés után a modul megfelelő tárhelyére kell feltölteniük.

Felhasználói környezet Az elkészült rendszer a felhasználók szempontjából platform független, tehát bármilyen operációs rendszerből elérhető. A design elkészítésénél kiemelt figyelmet fordítok arra, hogy az alkalmazás számítógépen, táblagépen és mobiltelefonon egyaránt megfelelő felhasználói élményt nyújtson. A termék használatának előnyei 2.1.4.1 Kérdőívekről általánosan A kinyerhető adatok hitelességét és megbízhatóságát nagyban befolyásolja a kérdések precíz megfogalmazása és a kérdőívek begyűjtésének módja. Főbb kérdőíves technikák: 

Személyes kérdezés kérdőívvel: A személyes kérdőív előnye, hogy jobban meghatározható az a célcsoport, amelytől információkat szeretnénk megtudni. Bonyolultabb kérdőív során az instruktor segítségével egyértelmű és pontos válaszokat kaphatunk a kérdésekre. Ennek a kérdezési módszernek a hátránya abban rejlik, hogy időigényes, valamint adott esetben sok instruktorra, szervezésre és tárgyi eszközre van szükség, ezért drága.



Telefonos kérdőíves kérdezés: Ez a módszer abban hasonlít az előzőre, hogy egy kérdező/instruktor bonyolítja le a kérdezést és rögzíti a válaszokat. Előnyt jelent az, hogy könnyebb biztosítani a válaszoló fél anonimitását. Ebben az esetben azonban nem használhatók segédeszközök, ábrák a kérdőívekben, így a kérdések pontosításánál lehetnek problémák.



E-mailben elküldött kérdőív: A korábbi módszerekhez képest sokkal olcsóbb technológia, hiszen nincs szükség sem instruktorokra, sem a kérdőívek 7

Misztina Péter


kinyomtatására. Hátránya, hogy csak egyszerűbb, rövidebb felmérésekre alkalmas, ezen kívül bizonyos társadalmi rétegek számára nem elérhető ez a módszer. Gondot jelent a válaszadó könnyű beazonosíthatósága is. 

Online felületen elérhető önkitöltős kérdőív: Előnye, hogy nem igényel a beérkezett válasz további kódolást. Egy megfelelő – jól áttekinthető, esztétikus – design elkészítésével rendkívüli módon növelhető a felmérés hatékonysága. A mai online társadalomban talán ez a leghatékonyabb módja kérdőívek készítésének. Hátrányként említhető, hogy az űrlap elkészítéséhez magasabb informatikai szaktudás szükséges, mint a korábbi módszerek esetében. Az űrlap kitöltése viszont nem okoz már problémát az átlagos felhasználók számára sem.

Kérdőíves technikákról bővebben a [18]-as linken olvashatunk. 2.1.4.2 Megvalósítandó kérdőívkezelő modul Az előző fejezetben megismert kérdőíves technikák közül két típus lesz megtalálható a szakdolgozatomat képező modulban. 

E-mailben elküldött kérdőív: A modul feladatai közé nem tartozik, hogy a kérdőíveket kiküldje a célszemélyeknek, valamint nem e-mailben kapja meg a rendszer a kitöltött kérdőíveket, hanem lehetőséget nyújt a korábban kiküldött űrlapok közvetlen betöltésére a rendszerbe.



Online felületen elérhető önkitöltős kérdőív: A dolgozói értékelés online kérdőív formájában lesz elérhető, melyet a rendszer automatikusan feldolgoz.

Látható tehát, hogy ezen technikák alkalmazása esetén komoly előnyökkel jár a feldolgozási folyamat automatizálása.

8

Misztina Péter


3 FELHASZNÁLANDÓ TECHNOLÓGIÁK, KUTATÁS A mai modern webfejlesztési elvárásokat figyelembe véve, egy web-programozónak többféle technológiát kell ismernie ahhoz, hogy a kornak megfelelő dinamikus, versenyképes alkalmazást készítsen. Néhány évvel ezelőtt még elég volt a HTML, CSS és netalán még egy kevés JavaScript ismerete a megfelelő és jól működő, az igényeket tökéletesen kielégítő weboldal készítéséhez. Napjainkban az a minimum, hogy egy honlapra be tudjunk jelentkezni. Már ennek a megvalósításához is szükség van valamilyen szerveroldali nyelv ismeretére. Közismert eszköz erre a PHP, amivel ma már inkább csak kisvállalatok és főleg magánszemélyek weboldalain találkozunk. A komplexebb webalkalmazások alapvetően két csoportba sorolhatók. Egy részük JAVA alapú. A JAVA nyelvet sokan preferálják platform független mivolta miatt. Ez valóban hasznos tulajdonság, hiszen bármilyen környezetbe kitelepíthető alkalmazás készíthető így. A másik nagyobb platform, amit a fejlesztők használnak a C# alapú ASP .NET. Ez a rendszer a Microsoft hatáskörébe tartozik, vagyis Windowsos környezetben fejleszthető és csak oda telepíthető ki.

A

kitelepített

rendszer

természetesen

(webalkalmazás lévén) már bárki számára elérhető, hiszen „akármilyen” böngészőben megtekinthető. Az akármilyen szót, azért tettem idézőjelek közé, mert az adott böngészőnek ismernie kell azokat a technológiákat, melyeket az alkalmazás használ. Napjainkban is jelenlévő probléma, hogy a fejlesztő által elkészített weboldal az egyes böngészőkben másmás módon jelenik meg. Ennek az oka a böngészők különböző felépítésében rejlik. A szakdolgozatom során készített alkalmazás ASP .NET MVC 5 technológiát használ. Ahhoz, hogy valaki egy korszerű rendszert készítsen, szükség van legalább az alábbi technológiák ismeretére: 

HTML 5,



CSS3,



Bootstrap,



jQuery,



Microsoft SQL, 9

Misztina Péter




Windows Azure,



ASP .NET MVC és



iTextSharp.

A következőkben szót ejtek két kiemelt technológiáról az imént felsoroltak közül, valamint egy tervezési mintáról. Elsősorban azokra a technológiákra térek ki, melyek ismerete szükséges az általam kifejlesztett modul megértéséhez. Az érintett a témák a következők: 

ASP .NET MVC



Repository Pattern



iTextSharp

ASP .NET MVC Ebben a fejezetben az ASP .NET MVC technológiával ismerkedünk meg, mely alappillérét képezi a készítendő rendszernek.

3.1.1.1 Mi is az MVC?

2. MVC modell Az MVC mozaikszó, melynek jelentése Model, View, Controller. Az elkészítendő rendszer ezen tervezési modell alapján épül fel. 

Model: A modell feladata az adatok rendelkezésre bocsájtása a többi réteg számára. 10

Misztina Péter




View: A view réteg felelős a felhasználói felületek kinézetéért és az adatok megjelenítéséért.



Controller: A controller maga a vezérlő, ami irányítja a másik két réteget.

Controller Mint ahogy fentebb említettem, az MVC modell Controller-jeinek a feladata vezérelni magát az alkalmazást. A Controller általában egy felhasználói input hatására válaszol. Valamilyen paraméterek vagy feltételek alapján egy Model-t állít elő, amit továbbít egy View-nak. Minden Controller-hez tartozik egy mappa a View könyvtárban és a Controller adott metódusa alapján hívódik meg a hozzá tartozó View. A böngésző címsorában látható URL-ből kiolvasható, hogy éppen melyik Controller melyik metódusa hajtódott végre.

3. MVC minta URL A 3-as ábárn jól látszik, hogy a Home Controller Index metódusa fut, tehát az alkalmazás nyitó oldala töltődik be. View Az előző bekezdésben már szó esett arról, hogy minden Controller-hez tartozik egy Viewkat tartalmazó könyvtár. Ebben a könyvtárban helyezkednek el az adott Controller metódusokhoz tartozó View-k. Érdemes azt a névkonvenciót tartani, hogy a View-nak olyan nevet adunk, mint ami az őt meghívó metódus neve. A View maga a felhasználói felület, amelyet a felhasználó lát. Itt zajlanak az interakciók, ami alapján az alkalmazás működik. A View alapvetően a HTML leíró nyelvet használja, de ide is kerülhet C#, JavaScript vagy CSS kód. Az MVC újabb verziói esetén, a View-ba a C# kódot Razor szintaktikával kell írni, ami azt jelenti, hogy minden kód elejét „@” jellel kell jelölni. A Razor tehát egy jelölő szintaktika, mely lehetővé teszi, hogy szerver kódot lehessen beágyazni a View-ba. Alapvetően kevés ilyen kód található a View-ban, mivel főleg listákon való léptetésekhez, vagy jogosultságkezelésre használjuk. A CSS és JavaScript kódokat általában külön fájlban írjuk, a View-ba csak egy link segítségével kerülnek be. A CSS a weboldal kinézetéért felelős, míg a JavaScript a kliens oldali tartalom manipulációjáért.

11

Misztina Péter


Model A Model a View számára szolgáltatja a felhasználandó adatokat. A modellek rendszerint a Models könyvtárban találhatók. Sok fejlesztő által kedvelt megoldás az Entity Framework használata a Model osztályok megadására. A View-ba linkelve a megfelelő Model osztályt érjük el annak adatait. Az ASP .Net MVC programozási modellről bővebben a [2], [15] és [16]-os irodalomjegyzékben tájékozódhat az Olvasó, példavideók és szakmai leírások keretében. 3.1.1.2 ASP .NET MVC a gyakorlatban A következő példa bemutatja, hogyan működik ez a rendszer egy konkrét alkalmazásban. public class CustomerController : Controller { public ActionResult Index() { return View(_customerManager.GetAllCustomers()); } } 4. MVC Controller osztály Ez a kódrészlet egy Customer Controller-t mutat be. Mint látható, egy metódussal rendelkezik, amely az Index oldal betöltéséért felelős. A View számára egy Customer-eket, azaz ügyfeleket tartalmazó listát ad tovább. @model IEnumerable<SurveyManager.Model.Customer> @foreach (var item in Model) { @Html.DisplayFor(modelItem => item.Name) } 5. MVC View felépítése Ebben a példában a View struktúrája látható. Definiálni kell számára egy modellt, amiből aztán adatokat lehet kinyerni a fent bemutatott módon. Ha a két kódrészletet egymás után nézzük, értelmet nyer az, hogy a Controller-ben átadott ügyféllistát milyen módon tudjuk megjeleníteni. Az MVC modell jól strukturálhatóvá és átláthatóvá teszi az alkalmazást, ezzel könnyítve meg annak fejlesztését, bővítését.

12

Misztina Péter


Repository Pattern Az informatikában a szoftverfejlesztés területén általános megoldások, trendek alakultak ki. Sok esetben a fejlesztőnek egy adott probléma megoldásához nem kell egy teljesen új rendszerstruktúrát felépítenie, hanem egy már meglévőt elegendő továbbfejleszteni, átalakítani. Ebből a célból különböző, úgynevezett Software Design Pattern-eket [4], azaz programtervezési mintákat fejlesztettek ki. A tervezési minták sokaságából csak egyet emelek ki, konkrétan a Repository Pattern-t. Mint korábban is említettem, a mai webes alkalmazásokban elengedhetetlen valamilyen adatbázis szerver használata. Ezen tárolódnak a felhasználói adatok, rendszer-adatok és egyéb információk. Mivel az alkalmazások általában rendszerezettek, így beszélhetünk egy Business Logic rétegről, ami az üzleti logika végrehajtásáért felel. Itt történnek a számítások és amennyiben nem megfelelően rétegezett az alkalmazás, a szerver elérése is itt történik. Ha visszagondolunk az MVC-ről olvasottakra, a hagyományos MVC struktúrában a Controller halmaz felel meg a Business Logic rétegnek. Belátható azonban, hogy ez a megoldás nem túl hatékony. Sok szempontból érdemes különválasztani a Data Access, azaz adatelérési réteget az üzleti logikától. Ha ezt nem tesszük meg, akkor az alkalmazás: 

sok ugyanolyan kódrészletet tartalmazhat,



nagyobb esély van a hibázásra,



nem szeparálható az adatok áramlása,



tesztelése nehézkessé válik.

Könnyen belátható tehát, hogy valamilyen megoldást kell találni ezekre a problémákra. Itt nyer értelmet a Repository Pattern használata. Ebben az esetben a rendszer tartalmaz Business Logic és Data Access réteget is, utóbbival kommunikálva az adatbázis felé.

6. Repository Pattern felépítése 13

Misztina Péter


Ezen minta használatával az alkalmazás a következő előnyöket biztosítja: 

könnyen tesztelhetővé válik, akár unit tesztek segítségével is,



az üzleti logika osztályainak bármelyikéből elérhető bármely Repository osztály,



jól szeparálható az adatok elérésének módja,



biztonságosabb adatelérés oldható meg az interfészek segítségével,



az üzleti logika számára erősen típusos, könnyen felhasználható adatforrást biztosít.

A Repository Pattern működése tehát úgy foglalható össze, hogy az adatbázissal a kapcsolatot a Data Acces rétegen keresztül valósítja meg, csak és kizárólag ez a réteg képes az adatbázis kommunikációra. Ezen kommunikáció során megszerzett adatokat továbbítja a Business Logic rétegnek, ahol azokkal adatmanipulációs műveletek végezhetőek. Végül ennek a rétegnek a megfelelő osztályát meghívva kerül el a kinyert adathalmaz a Controller számára, ami továbbítja őket a View-nak és így a felhasználó számára elérhető formában jelenik meg. A rétegek közötti kommunikáció Interface-ek segítségével valósul meg. A Repository Patternről bővebb információ az [5]-ös linken található. iTextSharp Az iTextSharp egy C# szerelvény, ami PDF dokumentumok kezelésére szolgál. Több olyan eszköz is elérhető, ami támogatja a PDF állományok menedzselését. Példaként a PDF Clown, FO PDF vagy a PDFJet említhető meg. Az előnyök és hátrányok megvizsgálása után, számomra a legjobb megoldásnak az iTextSharp tűnt, egyszerű használhatósága és könnyű integrálhatósága miatt. Az iTextSharp mellett szól az is, hogy ez a dll nyílt forráskódú eszköz. Letölthető a [3]-as linkről. 3.1.3.1 Milyen funkciókat tartalmaz az iTextSharp? Konkretizálva az előző fejezetben megemlített információkat, az iTextSharp egy olyan könyvtár, amely elősegíti PDF fájlok létrehozását, vizsgálatát és fenntartását. Segíti… 

dokumentumok létrehozását XML fájlokból vagy adatbázisból,



a PDF-manipulációt, azaz oldalszámok, vízjelek és egyéb PDF funkciók felhasználását,



PDF fájlok szétválasztását, összefűzését, 14

Misztina Péter




PDF űrlapok kitöltését, olvasását,



PDF űrlapok betöltését, generálását.

Mint látható, igen sok funkció megtalálható az iTextSharp-ban, melyek közül számomra az utolsó két lehetőség talán a legfontosabb. Ezen tulajdonságai miatt választottam a feladat megvalósításához ezt a könyvtárat. 3.1.3.2 PDF Űrlap olvasása, írása Az iTextSharp használatának egyszerűségét a következő példán keresztül szemléltetem, bemutatva azokat a funkciókat, melyeket használok a modul elkészítése során. A PDF file beolvasásához nem kell mást tenni, mint megadni, annak helyét, de akár egy byte array-t vagy egy file stream-et is adhatunk a PDF readernek. Mint látható, jelen esetben egy konkrét elérési út áll rendelkezésre: string pdfTemplate = @"../../../kerdoiv.pdf"; PdfReader pdfReader = new PdfReader(pdfTemplate); 7. PDF Reader használata Miután a PDF reader-be került a fájl, már szabadon használhatjuk arra, amire éppen szükség van. Most tehát egy PDF űrlapról van szó, így ki kell kiolvasni azokat a mezőket, melyekben lehet valamilyen számunkra értékes adat. Ezt a következőképpen tehetjük meg: static StringBuilder FieldNamesList(PdfReader pdfReader) { StringBuilder sb = new StringBuilder(); foreach (KeyValuePair<string, AcroFields.Item> de in pdfReader.AcroFields.Fields) { sb.Append(de.Key.ToString() + Environment.NewLine); } return sb; } 8. PDF Field nevének kiolvasása A fenti metódus kigyűjti a PDF-ben szereplő mezők neveit, így olvashatunk belőle, vagy írhatunk bele. Ezeket a funkciókat az iTextSharp library-ben előre elkészített metódusok alapján könnyen megvalósíthatjuk: static void FillFields(PdfReader pdfReader, string newFile) { 15

Misztina Péter


PdfStamper pdfStamper = new PdfStamper(pdfReader, new FileStream(newFile, FileMode.OpenOrCreate)); AcroFields pdfFormFields = pdfStamper.AcroFields; pdfFormFields.SetField("Check Box", "Yes"); pdfFormFields.SetField("Radio Button", "1"); pdfFormFields.SetField("Text", "Template"); pdfStamper.FormFlattening = false; pdfStamper.Close(); } 9. PDF Field kitöltése A SetField() függvénnyel egyszerűen kitölthető az űrlap bármely mezője, ha ismerjük a nevét. Természetesen egy űrlapon nem csak szabadszöveges beviteli mező létezhet. Ezek szemléltetéseképpen az alábbi három kontrol szerepel a példában: 

jelölőnégyzet,



rádió gomb,



szöveges beviteli mező.

A kiolvasás hasonlóképpen zajlik. Erre is van egy jól használható saját függvény, a GetField(). Az előző példában a SetField() helyére beillesztve, paraméterként a mező nevével tökéletesen működik: pdfFormFields.GetField("Text"); 10. PDF Field értékének kiolvasása 3.1.3.3 Összefoglalás Meggyőződésem szerint a fenti példák egyértelműen bizonyítják, hogy az iTextSharp megfelelő, sőt hatékony eszköz a feladatom szempontjából fontos PDF-manipulációk elvégzésére. E dolgozatban nem tértem ki az iTextSharp lehetőségeinek teljes bemutatására, megelégedtem azzal, hogy röviden felvázoljam a számomra legfontosabb feladatok megoldási módját.

16

Misztina Péter


4 FUNKCIONÁLIS KÖVETELMÉNYEK 4.1 ÁLTALÁNOS KÖVETELMÉNYEK A megtervezendő rendszer három különböző típusú kérdőív kezelésére lesz felkészítve. a) Munkatárs elégedettségi felmérés: Mivel a dolgozók jogosultak lesznek a rendszerbe való belépésre, elegendő a felmérést egy Sharepoint űrlapként létrehozni, melyet kitöltve adatbázisba mentjük az adatokat. Ezt a felmérést évente végezzük el, és az adatokat a felmérési időszak végén összegezzük. A Sharepoint űrlapokról a [17]-es linken olvashatunk bővebben. b) Megbízói értékelés: A megbízói értékeléseket adott időszakonként végzi a rendszer, olyan módon, hogy felkínál egy listát, amelyből ki lehet választani azokat a megbízókat, melyektől a vállalat véleményt vár. A kiválasztott cégek listaként jelennek meg, ahol lehetőség lesz feltölteni PDF formátumban az értékelő lapot. Ezt a rendszer O365-ben tárolja, egy Sharepoint dokumentum tárban, az adatokat pedig feldolgozva menti adatbázisba. Innen utólag linken lekérdezhetők a PDF-ek megbízónként. c) Alvállalkozói értékelés: Az alvállalkozókat minden egyes projekt zárásakor értékelni kell. A rendszer addig nem engedi lezárni a projektet, amíg ez az értékelés meg nem történt. Az adatokat a megbízói értékeléshez hasonlóan kezeljük, ezen kívül átlagot kell számítani a megadott értékekből: ez lesz az adott alvállalkozó minősítése.

4.2 USE CASE DIAGRAM Fogalma Használati eset (Use Case) diagram célja a rendszer bemutatása a felhasználó szemszögéből, valamint a rendszer funkcionális működésének és viselkedésének ismertetése. A Use Case diagram három fő elemből épül fel: 

Használati eset: A felhasználó által látható, a rendszer által megvalósított funkció vagy funkció csoport.



Aktor: A rendszerrel kapcsolatba kerülő személy/személyek/külső rendszer.



Kapcsolat: Az aktor és használati eset közötti viszonyrendszert definiálja.

A szoftverfejlesztési módszerekről a [9], [10] és [11]-es linkeken található bővebb leírás. 17

Misztina Péter


A modul használati esetei uc Kérdőív kezelő modul Use Case

Dolgozó

Munkatárs elégedettség űrlap kitöltés

Kitöltött űrlap feltöltése Megbízó Kiértékelt adatok megtekintése Projektvezető Adminisztrátor

Feltöltött űrlapok törlése

Kérdezendő megbízók kiválasztása

Megbízók kezelése

Felhasználók kezelése Alvállalkozók kezelése

Jogosultság kezelés

11. Használati eset diagram Az 11-es ábrán látható, hogy a rendszerben három személy vesz részt, akik két irányból csatlakoznak be a rendszer fő funkciójába. Különböző használati esetek kifejtése 4.2.3.1 Munkatárs elégedettségi űrlap kitöltése Dolgozó Fő aktor Rövid leírás

A megadott időszakban a dolgozó feladata a munkatárs elégedettség kérdőív feltöltése, mely ebben a használati esetben valósul meg.

Előfeltételek



Dolgozó bejelentkezett a rendszerbe

18

Misztina Péter


Események sorozata

Rendszer válasz

Aktor bemenet Felhasználói

1

kérdőív

menüpont kiválasztása. Üres űrlap betöltése.

2 Űrlap kitöltése.

3

Mentés elindítása. Adatok mentése.

4

Kitöltés

eredményének

kiírása. Utóhatás

Felhasználó által kitöltött űrlap mentésre kerül az adatbázisba.

Lehetséges hibák

Amennyiben a mentés sikertelen, a felhasználó értesítést kap róla, lehetősége van a kitöltés újra próbálására. A rendszer egy dolgozótól csak egy értékelést fogad el, valamint a kérdőív időszakon túli feltöltés nem lehetséges.

4.2.3.2 Kitöltött űrlap feltöltése Megbízó, Projektvezető Fő aktor Rövid leírás

A saját számítógépükön kitöltött kérdőíveket lehetőségük van betölteni a rendszerbe a fent említett aktoroknak. 

Előfeltételek

Űrlap kitöltése valamilyen PDF olvasó szoftver segítségével.

 Események sorozata

Bejelentkezés a rendszerbe. Aktor bemenet

1

Rendszer válasz

A megfelelő kérdőív feltöltő oldalra navigálás. Feltöltő felület megjelenítése.

2 3

Fájl feltöltése. Fájl beolvasása.

4

Fájl és adatainak mentése. Eredmény kiírása. 19

Misztina Péter


Utóhatás

A feltöltött PDF és a benne lévő adatok elmentésre kerülnek.

Lehetséges hibák

Nem megfelelő fájl feltöltése esetén a rendszer hibát ír ki. Ugyancsak hibára fut nem kitöltött űrlap esetén is.

4.2.3.3 Begyűjtött adatok megtekintése Projektvezető Fő aktor Rövid leírás

A vezetés számára hasznos információk találhatók a feltöltött űrlapokban, ezért biztosítani kell azok megtekinthetőségét.

Előfeltételek

Események sorozata



Bejelentkezés a rendszerbe.



Lennie kell feltöltött űrlapnak. Aktor bemenet

1

Rendszer válasz

Űrlapok megtekintő felületének megnyitása. Megtekintő nézet

2

megjelenítése. 3

Adott űrlap részleteinek kiválasztása. Bővített információ

4

megjelenítése. 5

Letölteni kívánt PDF kiválasztása. Fájl mentés ablak

6

betöltése. 7

Fájl helyének kiválasztása a számítógépen. Fájl mentése.

8 Utóhatás

Az űrlap mentésre kerül a felhasználó számítógépén.

Lehetséges hibák

Ebben a folyamatban csak abban az esetben léphet fel hiba, amikor a rendszer elveszíti a kapcsolatot az adatbázissal.

20

Misztina Péter


4.2.3.4 Feltöltött űrlapok törlése Adminisztrátor Fő aktor Rövid leírás

Feltöltött űrlapok törlésére akkor lehet szükség, ha hibásan kerültek be a rendszerbe, vagy valamilyen hiba miatt ugyanaz a kérdőív többször került feltöltésre.

Előfeltételek

Események sorozata



Bejelentkezés a rendszerbe.



Léteznie kell feltöltött űrlapnak. Aktor bemenet

1

Rendszer válasz

Az űrlap megjelenítő felületre navigálás. Megtekintő nézet

2

megjelenítése, törlés funkcióval. 3

Kiválasztott PDF törlése. Űrlap törlése a

4

rendszerből. Utóhatás

Az űrlap törlődik a rendszerből nem visszaállítható módon.

21

Misztina Péter


4.2.3.5 Kérdezendő megbízók kiválasztása Adminisztrátor Fő aktor Rövid leírás

A megbízók számára egy listában kell biztosítani az űrlap feltöltésének lehetőségét. Ezt a listát az adminisztrátor hozza létre az alapján, hogy mely megbízóknak lett kérdőív kiküldve. 

Előfeltételek Események sorozata

Bejelentkezés a rendszerbe. Aktor bemenet

1

Rendszer válasz

Megbízói kérdőív kezelő felület megnyitása. Felület betöltése

2

adminisztrátor jogosultsággal. 3

Kérdőív lista gomb kiválasztása. Felugró ablak

4

megnyitása a lista kiválasztásához. 5

Megfelelő megbízók kiválasztása. Mentés. Adatok mentése az

6

adatbázisba. Megbízói kérdőív felület újratöltése a lista alapján. Utóhatás

Megbízói lista elkészül, így a megbízók számára felépül a környezet, ahova a kitöltött PDF fájlokat feltölthetik.

Lehetséges hibák

Nem létezik olyan megbízó a rendszerben, amelyet ki kellene választani. Ebben az esetben az adminisztrátornak lehetősége van hozzáadni az új elemet, majd újra próbálni a lista elkészítését.

22

Misztina Péter


4.2.3.6 Adminisztrátori funkciók Ezeket a funkciókat csak a felsorolás szintjén említem meg, hiszen működésük hosszabb részletezés nélkül is érthető. 

Felhasználók kezelése: Felhasználók felvétele, törlése, szerkesztése.



Jogosultság kezelés: Adott felhasználóhoz megfelelő jogosultság hozzárendelése.



Megbízók kezelése: Megbízók felvétele, szerkesztése, törlése.



Alvállalkozók kezelése: Alvállalkozók felvétele, szerkesztése, törlése.

23

Misztina Péter


5 RENDSZERTERV 5.1 ER DIAGRAM Fogalma Az ER (Entity Relationship) diagram egy egyszerűsített szemantikai modell, mely egyszerű grafikai ábrákat használ az adatok modellezésére. Nem célja a teljes adatmodell ábrázolása, ugyanakkor egyszerűsége miatt meglehetősen elterjedt. [7] Három fő elemből áll: 

Egyed: A külvilágtól egyértelműen elhatárolhat, önálló elem.



Kapcsolat: Az egyedek között fennálló asszociáció.



Tulajdonság: Az egyedeket, kapcsolatokat jellemző mennyiség, információhordozó elem.

Kérdőív kezelő modul ER diagrammjai Ebben a fejezetben a modul fontosabb tábláinak ER modelljét mutatom be, melyeken keresztül átlátható lesz az alkalmazás működése, felépítése. A teljes táblastruktúra a következő fejezetben, a relációs modellben látható. erd Kérdőív kezelő modul ER

Name

Description

ID

ID CustomerSurveyPeriod

Name

Customer *

Email

*

ExpiredDate CreatedDate

Location

CreatedBy

12. Megbízói értékelési szakasz és Megbízó tábla és tulajdonságai A modul egyik fő feladata a kérdőívek begyűjtése, mint ahogy korábbiakban említettem, a megbízói kérdőíveket csak egy bizonyos időben, meghatározott megbízóktól kell begyűjteni. Ahhoz, hogy ezeket megfelelően tudjam tárolni, létrehoztam egy CustomerSurveyPeriod táblát. Ebben tárolandó a kérdőív időszakok adatai. Megadható az időszak neve, például Őszi értékelések, tárolható leírás hozzá, lejárati idő, létrehozó neve, létrehozás dátuma. Ezekkel az adatokkal tökéletesen leírható az adott periódus és a 24

Misztina Péter


későbbiekben könnyen visszakereshetővé válik a kérdéses időszak. Önmagában ez még nem lenne elegendő, hiszen ebből a táblából nem derül ki egyértelműen, hogy az adott időszakban mely Megbízóktól kell begyűjteni az űrlapokat, ezért kapcsolatot hoztam létre a Customer tábla és a CustomerSurveyPeriod tábla között. Így minden időszakhoz lehet megbízókat rendelni. A kapcsolat N/N típusú, hiszen egy időszakban több megbízótól is kell kérni értékelést, valamint a megbízók több időszakban is részt vehetnek. erd Kérdőív kezelő modul ER

FileName

UploadDate

UploadedPdfID

ProfessionalKnowledge

ID ID UploadedPDF

ContractorSurveyResult 1

FileData

1

JobQuality IsCustomerSurvey

GeneralAssessment

CreatedBy

Relations DeadLine

Administration

Documentation

13. Feltöltött PDF és Alvállalkozói értékelés eredmény táblák kapcsolata és tulajdonságaik Fontos pontja az alkalmazásnak a PDF tárolásának módja is. A feltöltött PDF-et két táblában tárolom. Az egyik táblában maga a PDF és a fájl információk kerülnek mentésre, a másik táblában pedig a PDF-ben található adatok tárolódnak. Természetesen egy fájlhoz nem tartozhat kétféle tartalom. Ezt egy UNIQUE Constraint segítségével valósítom meg. Így a Result táblában az UploadedPdfID egyedi értéket vehet csak fel. A megbízói kérdőív hasonló módon kerül mentésre.

25

Misztina Péter


erd Kérdőív kezelő modul ER

ID

Email

AccesFailedCount

UserName

ID EmailComfirmed

PasswordHash AspNetUsers

AspNetRoles *

*

IsSurveyFilled

SecurityStamp

LookoutEnabled

PhoneNumber

PhoneNumberComfirmed

Name

LookoutEndDateUtc TwoFactorEnabled

14. Felhasználók és Jogosultságok tábla kapcsolata és tulajdonságai A felhasználói táblában az alkalmazást használó userekről tárolok információkat. A tábla és mező struktúrát az MVC 5 framework adja, így nem igényel egyedi fejlesztést, csak abban az esetben, ha bővíteni akarjuk a tulajdonság halmazt. Jelen esetben egy mezővel bővült, ez pedig az IsSurveyFilled. Ennek a mezőnek a segítségével tartom nyilván, hogy az adott user kitöltötte-e a dolgozói kérdőívet. Vannak olyan mezők, melyek a felhasználók számára nem tartalmaznak hasznos információkat, csak a rendszer működéséhez kellenek. Például SecurityStamp. Ezeket a táblákat Code First megoldással hozza létre az alkalmazás, így az adatbázisban garantáltan létrejönnek. A Microsoft Identity 2.0 technológiáról bővebben a [12]- es linkre navigálva olvasható. A User és a User Role tábla között N/N-es kapcsolat van. Ennek az az oka, hogy egy felhasználóhoz is tartozhat több jogosultság, és egy jogosultsághoz is tartozhat több felhasználó.

5.2 RELÁCIÓS ADATMODELL Fogalma A Relációs Adatmodell egy olyan adatbázis tervezési módszer, mely során matematikai relációk formájában adjuk meg az adatbázis táblák közötti kapcsolatot. A modell nem foglalkozik a fizikai megvalósítással, csak a logikai adatbázis megtervezésére alkalmas. [8] A relációs adatbázis modell elemei: 

Mező: egy elemi tulajdonság leírására szolgál, lehet kulcs mező is. 26

Misztina Péter




Rekord: egységként tárolt mezők összessége.



Reláció: azonos típusú rekord-előfordulások halmaza. Kérdőív Kezelő Modul Relációs Modell

15. Entity Framework adatbázis modell A 15-ös ábrán az Entity Framework által az adatbázisból generált relációs modell látható. Az eltérés abban rejlik egy hagyományos relációs modellel szemben, hogy egyszerűsíti a kapcsolatokat, gondolok itt arra, hogy például a Customer és a CustomerSuveyPeriod közötti kapcsoló táblát nem jeleníti meg, csak a * jelölés látható mindkét táblánál. Természetesen ez nem jelenti azt, hogy a kapcsoló tábla nem létezik, hiszen az adatbázis kapcsolat nem jöhetne létre közöttük fizikailag. Ez csak az áttekinthetőséget segítő funkció, hogy nem jelenik meg a modellben a kapcsolótábla. Az Entity Framework azon kívül, hogy szemléletes módon ábrázolni képes adatbázis táblákat több fontos funkcióval is bír, közülük hármat kiemelek. 

Biztosítja az adatbázis táblák objektum orientált elérését. Egy osztály megfelel egy táblának és a benne lévő tulajdonságok pedig az adatbázis tábla mezőinek. Így az 27

Misztina Péter


alkalmazás fejlesztőnek nem szükséges mélyreható adatbázis ismeretekkel rendelkezni, mert az SQL kódot a framework generálja számára. 

Az Entity Framework támogatja adatbázisok code first létrehozását. Ez azt jelenti, hogy például a 15-ös ábra alapján lehet generálni egy adatbázist, melyet a webalkalmazás hoz létre ezen a frameworkon keresztül. A szakdolgozat során részben használom ezt a funkciót, az AspNetUsers és AspNetRoles, valamint a hozzájuk tartozó kapcsoló tábla code first megoldással jön létre. Ezzel a megoldással az alkalmazásba történő regisztráció és bejelentkezés akkor is lehetséges, ha a teljes táblastruktúra nem áll rendelkezésre.



A 3.1.1-es fejezetben már említést tettem arról, hogy a programozók olykor MVC modellként Entity Framework által készített osztályokat használnak. Mint mondtam, ezekből a táblákból C# osztályok készülnek, amik úgy épülnek fel, ahogyan a Modell osztályai, így a View számára tökéletesen megfelel ezen osztályok megadása.

Az előző fejezetben látott ER modellel szemben, a 15-ös ábrán láthatóak az adatbázis mezők, a kulcsok, valamint a fejlesztés során használt Navigation Property-ket is tartalmazza az ábra. A két kérdőív eredmény tároló táblát azért nem bontottam ki, sok mezőt tartalmaznak, nem lehet őket megfelelően elhelyezni az ábrán és ezáltal nem marad áttekinthető. Ezek a táblák a PDF dokumentumhoz illeszkednek így a mezők ismerete ezen dokumentum során nem fontos. Mint látható a 15-ös ábrán van két különálló tábla mely nem csatlakozik egyik másikhoz sem. Az egyik ilyen a Contractor tábla. Ennek a táblának a feladata az alvállalkozók nyilvántartása. A másik pedig a UserSurveyResult. Ebben a táblában tárolódnak a dolgozói kérdőívek eredményei. A kitöltő anonimitásának megtartása érdekében nem kapcsolódik az AspNetUser táblához, hiszen abban az esetben egyértelműen kinyerhető lenne, hogy kihez tartozik az adott válasz rekord.

5.3 FELÜLET TERVEK A felülettervek elkészítésére jó megoldást nyújt a Microsoft Office Power Point, ami tartalmaz olyan funkciót, mellyel egy szimpla diasorozat átalakítható képernyőtervekké. Ez a lehetőség több szempontból is hasznos. A fő előnye, hogy az elkészült képernyőképek az ügyfél számára könnyen prezentálható formába kerülnek. Programozói tudás nélkül elkészíthetőek ezek a tervek, hiszen egy oldalsó toolbar-ból választhatóak ki az elemek. Ez 28

Misztina Péter


a toolbar tartalmaz minden olyan elemet, ami megtalálható egy weboldalon. A Power Point nem csak weboldalak terveinek elkészítését támogatja, lehet készíteni, Windows Phone, Windows 8.1 app, Sharepoint képernyőképeket is. Az általam készített kérdőív modul tervezéséhez azonban elegendő volt a webes felülethez szükséges eszközök használata.

16. A Főoldal terve A 16-os ábrán a főoldal terve látható. Mivel ez nem a végleges rendszer, sok információ nem található rajta, de ezzel szemléltethetem a képernyőterv készítő funkcióit. A slide olyan keretet kap, mint egy böngésző, van benne böngészősáv, navigációs gombok és a weboldal helyére készíthetjük el a saját tervünket. Ebben a tervezetben fekete-fehér „színeket” használtam, így a későbbiekben még valószínűleg változni (szépülni) fog az oldal designja. A 16-os ábra a fő menüpontokat, elemeket és azoknak pozícióit hivatott bemutatni.

17. Bejelentkezés terve 29

Misztina Péter


A 17. ábrán a bejelentkezés terve látható. Mivel az alkalmazásban több szerepkörrel rendelkező felhasználó található, elengedhetetlen egy bejelentkező felület. A mai modern design alappillére a letisztultság és minimalizáltság. Ezen elveket követtem a felület kialakításakor.

18. Táblázat terve A megvalósítandó rendszer során, több felületen is táblázatos formában jelennek meg az adatok, erre az egyik jó példa a Megbízók adatait megjelenítő oldal. Egy webalkalmazás elkészítése során fontos szempont az egységesség. Ennek fényében elég egy táblázatos nézetet megtervezni, a többi helyen is ez lesz a mérvadó. A 18-as ábrán a Megbízói táblázat és információs oldal tervei láthatóak.

30

Misztina Péter


19. Dolgozói értékelés terve A dolgozói értékelő űrlap fontos pontja a modulnak. A 19-es ábrán látható felületen gyűjti be az elégedettségi értékeléseket a rendszer. Minden kérdésnél két választ lehet adni, de a tartózkodás is lehetséges. Amennyiben a dolgozó tartózkodik, a rendszer ahhoz a kérdéshez nem ment el értéket. Ez a válaszlehetőség egy jelölőnégyzet formájában jelenik meg a felületen. Amennyiben ez bepipálásra kerül, a rendszer letiltja az ahhoz a kérdéshez kapcsolódó rádió gombokat. Ha kérdezett úgy dönt, hogy válaszol a kérdésre, két részre bomlik a kérdés. Az egyik az elégedettség mértéke, a másik pedig, hogy ez mennyire fontos az ő munkájához. Például: „Összességében milyennek ítéled meg a munkádhoz szükséges munkakörülményeket?” Először tehát meg kell válaszolni egy egytől ötig terjedő skálán, hogy mennyire elégedett, aztán pedig azt, hogy véleménye szerint mennyire fontos ez a kérdés. Az összes kérdés megválaszolása után a mentés gombra kattintva befejeződik az űrlap kitöltése.

31

Misztina Péter


20. PDF feltöltés terve A PDF feltöltés, mentés a rendszerben egyszerű módon van megvalósítva. A felhasználótól kevés interakció segítségével töltheti fel a kívánt fájlt, melynek a kiválasztása után, így egy letisztult felületen történik meg a feltöltés. A 20-es ábrán látható, hogy a felhasználónak két gomb áll rendelkezésére, az egyikkel kiválasztja a file-t, a másikkal pedig feltölti azt. Abban az esetben, ha nincs kijelölve fájl, a rendszer nem engedi a feltöltést.

32

Misztina Péter


6 PROOF OF CONCEPT 6.1 BEVEZETÉS A „Proof of concept” (továbbiakban: POC) angol nyelvű informatikai szakkifejezés. Magyar fordítása a „megvalósíthatósági példa” lehet. A POC egy adott rendszer vagy ötlet, javaslat, megoldási módszer megvalósíthatóságának bizonyítása. Az elemzésnek pozitív és negatív eredménye is lehet: adott esetben az is hasznos információ, hogy a kérdéses elképzelés nem valósítható meg az előzetes tervek szerint. A POC-ről bővebb információ a [6]-os linken található. A műszaki életben is használják a POC kifejezést, ha például a mérnök készít egy olyan mintadarabot, amely esetében nem számít annak kinézete vagy az elkészítési módja, csak az a fontos, hogy a kívánt funkciót tökéletesen ellátja-e? Az informatikában készített POC-nak is az a feladata, hogy megvizsgálja, hogy egy adott probléma megoldható-e az elképzelt eszközökkel. Természetesen abból, hogy a POC eredménye megfelelő, még nem következik, hogy a módszer eléggé hatékony (a „legjobb”), és az éles rendszerbe is biztosan bekerül majd. Az én esetemben egy kérdőív-kezelő modulról van szó, ami PDF űrlapok feldolgozását hajtja végre. Mint említettem, a POC készítése során nem követelmény a lefejleszteni kívánt rendszer teljes modellezése, jelen esetben azonban próbáltam törekedni a minél teljesebb vizsgálatra.

6.2 FEJLESZTÉS A POC konkrét készítése során az alábbi technikai előfeltételeket tekintettem adottnak: 

A rendszert ASP .NET MVC 5-ben kell elkészíteni.



iTextSharp dll segítségével célszerű feldolgozni a PDF-eket.



Microsoft SQL 2014 szerveren tárolom az adatokat.

A rendszer elkészítéséhez a Visual Studio 2013-at használtam, mivel tapasztalataim szerint ez a fejlesztő eszköz a legalkalmasabb az ilyen jellegű feladatok elvégzéséhez. Kiváló intelisense található benne, ami a programozás során nagyban egyszerűsíti a programozó dolgát. A készítendő POC alkalmazásnak a Survey Manager nevet adtam, így a továbbiakban ezen a néven fogok rá hivatkozni. 33

Misztina Péter


Repository Pattern használata A 3.1.2-es fejezetben volt szó a Repository Patternről és használatának fontosságáról. Ennek megfelelően az alkalmazást ennek a mintának megfelelően készítettem el. Visual Studio Solution Explorer segítségével jól szemléltethető a létrejött projekt struktúra, melyben megfigyelhetőek a Repository osztályok és az őket használó Business Logic rétegben található Manager osztályok.

21. Projekt struktúra Egy példán bemutatva még érthetőbbé válik a rendszer működése. Válasszuk ki a Repository osztályok közül a UserRepository osztályt és nézzük meg annak az egyik metódusát. public List GetAllUsers() { using (var db = new SMDatabaseEntities()) { var users = db.AspNetUsers.Include(r => r.AspNetRoles).OrderBy(u => u.UserName).ToList(); return users; } } 22. UserRepository GetAllUsers metódusa

34

Misztina Péter


Az itt látható metódus az adatbázis AspNetUsers táblájából kinyeri az összes felhasználót a hozzá tartozó jogosultságokkal, és felhasználónév szerint sorba rendezve egy listába helyezi, majd ezzel a listával tér vissza. Az üzleti logika hasonlóan elnevezett osztálya a következőképpen nyeri ki ezt a listát: public List GetAllUsers() { return _userRepository.GetAllUsers(); } 23. UserManager GetAllUser metódusa A Manager osztályban, mint látható, már nincs semmilyen adatbázis-hívás, egy az egyben a kapott listát adja tovább. Lehetne még különböző adatmanipulációs eljárásokat végezni, de magához az adatbázishoz ebből a rétegből már nem férünk hozzá. Bár korábban nem volt szó erről, de a projektstruktúra korábban bemutatott ábráján is látható a Web réteg. Itt található a Controller osztály, aminek szüksége van ezekre az adatokra, így itt hívjuk meg a Manager osztály megfelelő metódusát. public ActionResult Index() { return View(_userManager.GetAllUsers()); } 24. UserController Index metódusa Így a Repsoitory rétegben elindított adat elérte a célját, innen már a View-hoz kerül és megjelenik a felületen.

25. Dll struktúra 35

Misztina Péter


A Visual Studio 2013 segítségével lehet készíteni különböző szemléltető UML diagramokat az elkészült rendszerről. Lehetőségem volt tehát elkészíteni a 25-ös ábrát, mely szemlélteti a solution-ben elhelyezkedő dll-ek kapcsolatát. Megfigyelhető a megoldás tagoltsága, ami jelentősen segíti az egyes részek önálló tesztelhetőségét és nagyszerűen szemlélteti a felhasznált Design Pattern fizikai megvalósulásának formáját.

iTextSharp használata a POC-ban Mint korábban említettem, a POC azért készült el, hogy kidolgozása során megvizsgáljam a PDF űrlap feldolgozásának néhány „reményteli” módszerét, döntést hozzak, majd megállapítsam, hogy a legjobbnak tűnő eljárást lehet-e alkalmazni a beágyazó rendszerbe készítendő modul esetén. A 4.1.3-as fejezetben már szó volt az iTextSharp nevezetű szerelvényről, amely a PDF dokumentumok feldolgozását segíti elő. Ezt az eszközt építettem bele a rendszerbe oly módon, hogy helper osztályt hoztam létre, melynek egy metódusa megkapja a feltöltött PDFet és egy Dictionary-ban visszaadja a PDF Field nevét és értékét egy kulcs-érték párban, mint ahogy ez a 26-os ábrán látható. public Dictionary<string, string> GetValuesFromFields(byte[] pdfFile) { PdfReader pdfReader = new PdfReader(pdfFile); AcroFields pdfFormFields = pdfReader.AcroFields; Dictionary<string, string> pdfFieldValues = new Dictionary<string, string>(); foreach (KeyValuePair<string, AcroFields.Item> item in pdfFormFields.Fields) { pdfFieldValues.Add(item.Key.ToString(), pdfFormFields.GetField(item.Key.ToString())); } return pdfFieldValues; } 26. PDF Field értékek Dictionary-be töltés Ezután már nem volt már más feladat, mint adatbázisba menteni az értékeket és elmenteni a feltöltött PDF űrlapot is. A Helper osztály, azért jó megoldás, mert bármikor cserélhető, bővíthető anélkül, hogy a rendszert nagyobb mértékben módosítanánk. 36

Misztina Péter


A logika elkészítésével nem volt különösebb probléma, azonban a tesztelés során egy érdekes hiba merült fel. A megbízó cégtől kaptam egy minta űrlapot, melynek a feldolgozását meg kell valósítani a kész rendszerben. Úgy gondoltam, hogy ezzel a fájllal tesztelek, hiszen így még közelebb áll a készítendő alkalmazáshoz a tesztrendszer működése. Ezzel a PDF-fel tesztelve azonban nem várt hiba következett be. A rádió gomb értékét nem tudta kiolvasni a rendszer, csak azzal az értékkel tért vissza, hogy ki van-e töltve vagy sem. Több napot töltöttem a hiba keresésével. A feldolgozó rendszerben kerestem a hibát, aztán, mert a hiba csak nem akart előkerülni, készítettem egy saját teszt PDF űrlapot. Ezt használva a probléma nem jelentkezett többé, ezért bizonyos, hogy a probléma forrása a nem megfelelően elkészített űrlap volt. Felületek megvalósítása Ebben a fejezetben az 5.3-as pont alatt megtervezett felületek fizikai megvalósulásáról lesz szó. A megvalósítások néhol eltérnek a tervezettől, de az alapvető elemek és pozíciók minden esetben felfedezhetőek a kész rendszerben.

27. Kezdőlap adminisztrátorként bejelentkezve A 16-os ábrán látható volt a kezdőlap terve, ami a fent látható módon valósult meg. Maga az alkalmazás zöld hátteret kapott, ami nyugtatja a szemet. A képernyőtervhez képest az adminisztrátor felület úgy módosult, hogy a kezdőlapon lehetőség van minta PDF űrlapok letöltésére, így a rendszer tesztelése, hibakeresése könnyebben megvalósítható. A többi felhasználói csoport számára ez a rész rejtve marad.

37

Misztina Péter


28. Login képernyő A bejelentkező felület nem változott a tervekhez képest. A Bootstrap formázási lehetőségeit kihasználva készült el. A Bootstrap-ről részletesebb információk a [13]-as linken találhatók.

29. Táblázat megvalósítása A táblázat elkészítése a képernyőtervet (18. ábra) követve jött létre. Egy eltérés fedezhető fel benne. A sorok egyformák, azonban ha a felhasználó egy adott sorra húzza a kurzort, az a sor kiemelkedik a többi közül. Így látványosan és egyértelműen megkülönböztethető az aktív sor a többitől.

38

Misztina Péter


30. Dolgozói értékelés A dolgozói értékelés megvalósítása a 30-as ábrán látható. Természetesen a későbbiekben az igények alapján több kérdés vihető fel, ezek csak teszt kérdések, melyek a POC-hoz szükségesek. Bootstrap űrlapról van szó, így egy megadott keretrendszerben készült el az űrlap, melybe egy egyedi funkciót is bele kellett építeni. Abban az esetben, ha a felhasználó nem kíván választ adni a kérdésre, a beviteli mezőket le kellett tiltani. Ehhez a következő kliens oldali javascript-et írtam meg. @section Scripts { <script> $("#AnswerCheckBox").click(function () { if ($("#AnswerCheckBox:checked").val()) { $("input[name='AnswerImportance']").attr('disabled', true); $("input[name='AnswerSatisfaction']").attr('disabled', true); } else { $("input[name='AnswerImportance']").attr('disabled', false); $("input[name='AnswerSatisfaction']").attr('disabled', false); } }); } 39

Misztina Péter


31. Rádió gomb letiltása jQuery-vel A 31-es ábrán lévő kódrészlet egy jQuery szkript. A jQuery egy gyors, funkciókban gazdag JavaScript könyvtár. Részletesebb információ a [14]-es linkre navigálva olvasható róla. A fenti szkript tehát az oldal betöltődése után folyamatosan figyeli az „AnswerCheckBox” idvel ellátott input mezőt. Tehát a Not answer jelölőnégyzetét - és abban az esetben, ha az értéke igazra vált, letiltja a kérdéshez tartozó rádió gombokat. A 30-as ábrán látható mind a két állapot, amikor le van tiltva, és amikor nem. Ezzel a bővítéssel már minden esetre fel van készítve az űrlap.

32. Kérdőív feltöltés képernyőképe A PDF-feltöltés esetében sem volt szükség eltérni az előre elkészített képernyőtervtől, így, mint ahogy az a 32-es ábrán látható, az előzetes tervekkel megegyezően készült el a felület. Furcsa lehet, hogy az angol nyelvezetű alkalmazásban magyar szöveggel jelenik meg a fájlfeltöltő gomb és a hozzá tartozó szöveg. Ennek az oka, hogy a böngésző a file inputok megjelenítése során a számítógép területi nyelvi beállításai alapján készíti el a gombot és a

40

Misztina Péter


feliratot.

33. Multiselect dropdown list A 4.2.3.5-ös használati eset megvalósítása egy felugró ablakban történt meg. Az admin számára elérhető a megbízói kérdőív oldalon egy gomb, amely megnyomása esetén felugrik a 33-as ábrán látható ablak. Itt kiválaszthatóak a megbízók és a megadható a kérdőív időszak lejáratának ideje. Két főbb érdekesség is van ezen a felületen. Az egyik ezek közül a multiselect dropdownlist. Ennek az elkészítését támogatja a Bootsrtap, egyedi fejlesztésként megvalósítani elég nehézkes lenne és sok JavaScript kódot igényel. A következő programkód az elkészült megoldást mutatja be. <select id="askedCustomerList" multiple="multiple"> @foreach (var item in Model) { } $(document).ready(function () { $('#askedCustomerList').multiselect({ nonSelectedText: 'Check an option!', numberDisplayed: 1, enableFiltering: true, enableCaseInsensitiveFiltering: true }); }); 34. Multiselect dropdownlist html kódja és a hozzá tartozó jQuery A 34-es ábrán látható tehát, hogy egy hagyományos html select felhasználásával írtam meg a legördülő listát, melybe a Controller-től kapott modell általam kiválasztott elemeit rakom bele egy foreach segítségével. Ahhoz, hogy a multiselect funkciót aktiváljuk, a fent látható 41

Misztina Péter


jQuery utasítást kell meghívni a select-re. A megfelelő paraméterezéssel testre szabhatjuk a működését.

35. Bootstrap datepicker A másik érdekesség a Bootsrtap datepicker. A dátum választó nagymértékben megkönnyíti az űrlapok kitöltését, hiszen nem kell begépelni az időpontot, elég kiválasztani egy naptárból. A fent említett dátum választó azért jó választás, mert egyszerűen testre szabható, kevés egyedi fejlesztést igényel. $('.datepicker').datepicker({ format: 'yyyy.mm.dd.', startDate: '-0d' }) 36. Datepicker megvalósítása A 36-os ábrán látható módon lehet beépíteni a rendszerbe a dátumválasztót. A html input tagnek tartalmaznia kell egy datepicker class-t, ennek segítségével kapja meg a CSS kódot és a jQuery is ezen a class-on keresztül éri el. Különböző paraméterek megadásával egyedivé tehető ez a kontroll. Ahogy az a program kódrészletben is látható, dátum formátumot állítottam be, valamint a kezdő dátumot, így nem lehet a múltban megadni lejárati dátumot, hiszen ez értelmetlen lenne. Responsive design Bár a POC elkészítése során külön nem volt feladat responsive design elkészítése és – idő hiányában – nem is fektethettem rá különösebben nagy hangsúlyt, de mert a beágyazó rendszer Bootstrap technológiát használ, ezért én is ezzel készítettem el az alkalmazást. Így 42

Misztina Péter


komolyabb időráfordítás nélkül is igényes, különböző felbontásokban is megfelelő kinézetű alkalmazást lehet készíteni.

37. POC webalkalmazás nyitó lapja Nagyfelbontású monitorról megtekintve a 37-es ábrán látható képernyőképet láthatjuk, mobiltelefonról nézve pedig a 38-as ábrán megtekinthető kép fogad minket.

38. POC webalkalmazás mobiltelefon felbontásban Látható tehát, hogy a modern technológiák nagymértékben segítik a fejlesztést és lehetővé teszik magasabb szintű felhasználói élmény elérését.

43

Misztina Péter


7 ÖSSZEFOGLALÁS A feladatom egy kérdőív kezelő modul elkészítése volt, mely többfajta kérdőív fogadására és feldolgozására is alkalmas. A rendszer egy ASP .Net MVC 5-ös „Proof of concept” alkalmazásból fejlődött ki. A munka során először is bizonyítottam a feladat megvalósíthatóságát. Az elkészült webalkalmazás önállóan is megállja a helyét, de egy nagyobb rendszerbe történő integrálása is megoldható. A következő funkciók valósultak meg. Dolgozói értékelés Az előzetes tervezés alatt Sharepoint űrlapként képzeltem el ezt a funkciót, azonban a megvalósítás során végül egy MVC 5-ös alkalmazás részeként, webes űrlap formájában készítettem el. Azért választottam ezt a megoldást, mert így a rendszer egységesen működő alkalmazásként tud funkcionálni, emellett a POC-al szemben támasztott követelményeknek is teljes mértékben megfelel. Ha a későbbiekben arra kerül a sor, akár önálló webalkalmazásként is használható a rendszer. Bővítése, továbbfejlesztése is viszonylag könnyen megoldható. Megbízói és Alvállalkozói kérdőív Ezt a két funkciót kezelhetjük egyben is, hiszen a megbízói kérdőív feltöltése hasonló az alvállalkozói kérdőív feltöltéséhez. Maga a megvalósított feldolgozó mechanizmus tulajdonképpen meg is egyezik. A fő eltérés abban fedezhető fel, hogy míg az alvállalkozói kérdőív feltöltés csak egy PDF feltöltő és mentő funkció, addig a megbízói kérdőív feltöltéséhez egyéb követelmények is tartoznak. Gondolok itt arra, hogy meg kell tudni adni a kérdezendő megbízókat, és a kérdőív időszak lejártát is. Ezek a funkciók plusz tervezési és fejlesztési problémákat vetettek fel, melyeket sikeresen leküzdöttem. Előre nem definiált funkciók A tervezés kezdeti stádiumában voltak kérdéses funkciók, feladatok, megoldási menetek, amik nem voltak előre definiálva. A kezdeti tervezetben ez a kérdőív kezelő csak egy modulja lett volna egy nagy intranetes rendszernek, azonban közben olyan döntés született, hogy egy különálló rendszer készüljön belőle. Az első elképzelések szerint a PDF-ek és egyéb tartalmak mentése O365-re történt volna. Mivel a rendszer nem Sharepoint Online-on lett megvalósítva, az O365 használata indokolatlanná vált, ezért az adatbázisba való mentést kellett megtervezni és megvalósítani. 44

Misztina Péter


A jogosultság kezelés problémakörével alapvetően nem kellett volna foglalkoznom a rendszer létrehozása közben, mert egy előre elkészített struktúrában helyezkedett volna el az alkalmazás. Mivel végül saját fejlesztésű rendszer készült el, ezt a feladatot is el kellett végeznem. Az agilis tervezésnek és fejlesztésnek nagy hasznát vettem, hiszen ezáltal sikeresen tudtam alkalmazkodni a kialakult helyzethez és megoldást tudtam találni a problémákra.

7.1 TOVÁBBFEJLESZTÉSI LEHETŐSÉGEK A rendszer olyan szempontból kész van, hogy azokat a funkciókat, melyeket előzetesen definiáltunk, tartalmazza. Ugyanakkor vannak olyan új funkciók, amiket a rendszerbe beleépítve akár önálló terméknek is lehetne tekinteni. Ezek közül kettőt vázlatosan be is mutatok. Levélküldés Az egyik ilyen funkció egy komplex levélküldő rendszer beépítése lehet. Ha ez megtörténne, akkor a dolgozókat és a megbízókat levélben értesítené a rendszer az adott értékelési időszakról és a teendőikről. Egy figyelő mechanizmussal értesítéseket vagy emlékeztetőket lehetne küldeni számukra. Ezzel gyorsulna, és könnyebben visszaellenőrizhetővé válna a rendszer működése. A felhasználóknak egyértelműen meg lenne szabva az idő, amikor az értékelést el kell végezniük, valamint a postafiókjukban megjelenne a felszólító e-mail, így biztosabban megtörténne a feladat végrehajtása. Az adminisztrátorok és a vezetők is emailben értesülnének arról, hogy kik töltötték ki a kérdőívet és kik nem. Természetesen a felhasználók anonimitása így is megmaradna, hiszen a rendszer csak azt tárolja, hogy az adott személy kitöltötte-e a kérdőívet, azt nem, hogy melyik válasz tartozik hozzá. Értékelések összegzése Jelenleg az értékelések összegzése csak táblázatban, számok formájában jelenik meg. Ennek a modulnak a továbbfejlesztése is célszerűnek tűnik. A jövőre nézve alapvető elvárásként fogalmazható meg, hogy a nehezen kiértékelhető táblázatok mellett jól áttekinthető grafikonokat is előállítson a rendszer. A látványos és jól megtervezett grafikonok igen nagy segítséget jelenthetnek a kiértékelés során. Egy trend észrevétele például egy táblázatból szinte lehetetlen, de egy jól eltalált grafikonon könnyen szembeötlik. De további előnyökkel is számolhatunk, például azzal, hogy a megbeszéléseken mindenki által érthető formában lehetne bemutatni az eredményeket. Célszerű majd arról is gondoskodni a fejlesztés során,

45

Misztina Péter


hogy a diagramokat esetleg PDF formátumban is kiexportálhassa a felhasználó, megkönnyítve így a statisztikusok feladatát.

46

Misztina Péter


8 SUMMARY My project was to create a survey manager module, which can receive and process some types of surveys. The system is an upgraded version of an ASP .NET MVC 5 „Proof of concept” web application. In the beginning I have proofed that the task can be solved. At the end of the development I made a standalone web application, which has all of the features that I had defined earlier. Look at these features. Employee survey At the time of the previous planning, in my mind this feature was a Sharepoint survey form, but finally I made a MVC 5 form, because it can easily fit to the other part of the system, and it was an easier solution. By the way it was totally enough for the specification of the POC. If I need to do some development in the future I will be able to solve it, because the system can be upgraded easily. Customer and Contractor survey The customer survey upload is similar to the contractor survey upload. The working process is similar, but there is a little difference. The contractor survey feature is just a PDF form upload and a save function, but the customer survey feature has extra functions. For example the application has to assign the survey period to the specified customer and the administrator has to be able to add an expired date to the chosen period. These features and functions gave me extra planning problems but finally I solved them. Not specified features At the beginning of the planning there were some undefined features, functions. For example this survey manager app was just a module of a bigger intranet system, but it grew to a standalone webapplication. The first imagine was that the PDF files and the data would be saved at the O365. Later I decided that it could be enough to save them to a local database, because the finished application will not be deployed to Sharepoint Online. So I had to figure out how to fix this issue, and it generated more planning time. If this system is a module of an intranet system, I do not need to think about the identity management, because it comes from the system. But my app cannot use this advantage, so I had to develop an identity management module to my application. Fortunately I could pass these problems and I could adjust to all predicament. 47

Misztina Péter


8.1 POSSIBLE FUTURE DEVELOPMENT The system is technically done. It has all that features that I defined at the beginning of the document, but there are some new features which can improve the user experience. Let us take a look two of them. Mailing module The first feature can be a mailing module. If the system got this it can let the employees and the customers to know about the actual survey. With a watching mechanism the application can send mails to the users to remind them to their tasks. The survey process can be faster and can be checked easier in that way. The users can exactly know when they have to do their works and what except the system from them. The admins and the leaders can check who did the survey and who did not. For sure the employees anonymity still works, because the application saves that who did the survey but does not assign the survey to a person. Charts Now we can see the result in simple table views. It is enough now, but it is a good way to raise the experience. In the future it could be a good idea to develop a page where the users can watch the result in charts. It is good for presentations, and everybody can understand a chart easier, then wall of numbers. For example in a good waveform graph we can easily find a pattern. By the way if the chart module works well, the app should have a new feature, that the possibility of exporting the chart to PDF. It could be good for moving data and give a writing way of the survey result.

48

Misztina Péter


9 IRODALOMJEGYZÉK [1]. http://www.abesse.hu/abesse [2]. http://nyelvek.inf.elte.hu/leirasok/ASP.NET/index.php?chapter=5 [3]. http://sourceforge.net/projects/itextsharp/ [4]. http://hu.wikipedia.org/wiki/Programtervez%C3%A9si_mint%C3%A1k [5]. http://msdn.microsoft.com/en-us/library/ff649690.aspx [6]. http://www.proz.com/kudoz/english_to_hungarian/engineering_general/5064235proof_of_concept.html [7]. http://www.iit.uni-miskolc.hu/iitweb/export/sites/default/department/labs/iitszolgaltatasok/www-db/Tantargyak/AB1/ab1-03_uj.pdf [8]. http://www.iit.uni-miskolc.hu/iitweb/export/sites/default/department/labs/iitszolgaltatasok/www-db/Tantargyak/AB1/ab1-05_uj.pdf [9]. http://users.iit.uni-miskolc.hu/~mileff/szt/folia/SWtech_UML_2.pdf [10]. http://users.iit.uni-miskolc.hu/~mileff/szt/folia/SWtech_UML_1.pdf [11]. http://www.inf.unideb.hu/kmitt/konvkmitt/szoftverfejlesztes/book.xml.html#id30 9585 [12]. http://www.codeproject.com/Articles/762428/ASP-NET-MVC-and-IdentityUnderstanding-the-Basics [13]. http://getbootstrap.com/css/#forms [14]. http://jquery.com/ [15]. http://www.pluralsight.com/courses/aspdotnet-mvc5-fundamentals [16]. http://www.microsoftvirtualacademy.com/training-courses/developing-asp-netmvc-4-web-applications-jump-start [17]. http://www.c-sharpcorner.com/UploadFile/54db21/create-survey-in-sharepoint2010-programmatically-using-vs-2/ [18]. https://www.felvi.hu/pub_bin/dload/DPR_Kezikonyv/Mellekletek/technikak_elon yei_es_hatranyai.pdf [19]. http://office.microsoft.com/hu-hu/

A linkek utoljára ellenőrizve: 2014. november 24.

49

Misztina Péter


10 ÁBRAJEGYZÉK 1. Beágyazó rendszer felépítése 2. MVC Modell 3. MVC minta URL 4. MVC Controller osztály 5. MVC View felépítése 6. Repository Pattern felépítése 7. PDF Reader használata 8. PDF Field nevének kiolvasása 9. PDF Field kitöltése 10. PDF Field értékeinek kiolvasása 11. Használati este diagram 12. Megbízói értékelési szakasz és Megbízó tábla és tulajdonságai 13. Feltöltött PDF és Alvállalkozói értékelés eredmény táblák kapcsolata és tulajdonságaik 14. Felhasználók és Jogosultságok tábla kapcsolatai és tulajdonságai 15. Entity Framework adatbázis modell 16. Főoldal terve 17. Bejelentkezés terve 18. Táblázat terve 19. Dolgozói értékelés terve 20. PDF feltöltés terve 21. Projekt struktúra 22. UserRepository GetAllUsers metódusa 23. UserManager GetAllUser metódusa 24. UserController Index metódusa 25. Dll struktúra 26. PDF Field értékek Dictionary-be töltés 27. Kezdőlap adminisztrátorként bejelentkezve 28. Login képernyő 29. Táblázat megvalósítása 30. Dolgozói értékelés 50

Misztina Péter


31. Rádió gomb letiltása jQuery-vel 32. Kérdőív feltöltés képernyőképe 33. Multiselect dropdown list 34. Multiselect dropdownlist html kódja és a hozzá tartozó jQuery 35. Bootstrap datepicker 36. Datepicker megvalósítása 37. POC webalkalmazás nyitó lapja 38. POC webalkalmazás mobiltelefon felbontásban

51

Kérdőív kezelő modul fejlesztése információs rendszerben Szakdolgozat

Recommend Documents