Skeddl: Difference between revisions
No edit summary |
|||
(12 intermediate revisions by 3 users not shown) | |||
Line 38: | Line 38: | ||
Rakendus koosneb kahest põhilisest osast: veebiklient ja server. | Rakendus koosneb kahest põhilisest osast: veebiklient ja server. | ||
Projekt realiseeritakse kasutades ASP.NET MVC Web API tehnoloogiat. | |||
Esialgne rakenduse ülesehituse skeem: | |||
[[File:Program_architecture.PNG]] | |||
Line 57: | Line 63: | ||
** Peab olema võimalik kasutajaks registreerida (st kasutajakonto olemasolu on kohustuslik programmi kasutamiseks); | ** Peab olema võimalik kasutajaks registreerida (st kasutajakonto olemasolu on kohustuslik programmi kasutamiseks); | ||
** Kasutaja peab saama sisse logida kasutajanime (st e-maili aadressi) ja parooliga; | ** Kasutaja peab saama sisse logida kasutajanime (st e-maili aadressi) ja parooliga; | ||
** Korraga saab rakendusse olla sisse logitud mitu kasutajat. | |||
** Paroolile peavad rakenduma keerukusnõuded (nt 8 tähemärki, suurtäht, väiketäht, number, sümbol); | ** Paroolile peavad rakenduma keerukusnõuded (nt 8 tähemärki, suurtäht, väiketäht, number, sümbol); | ||
** Kasutajatel peavad olema erinevad õiguste tasemed (minimaalselt tavakasutaja ja adminkasutaja/poweruser); | ** Kasutajatel peavad olema erinevad õiguste tasemed (minimaalselt tavakasutaja ja adminkasutaja/poweruser); | ||
Line 110: | Line 117: | ||
* Grupiga liitumiseks taotluse esitamine. Taotluse peab kinnitama grupi omanik | * Grupiga liitumiseks taotluse esitamine. Taotluse peab kinnitama grupi omanik | ||
* Grupist lahkumine | * Grupist lahkumine | ||
==== Server ==== | ==== Server ==== | ||
<b>Serveri must-have funktsionaalsus</b><br> | <b>Serveri must-have funktsionaalsus</b><br> | ||
Server peab toetama kõiki klientrakenduse must-have nõudeid. | * Server peab toetama kõiki klientrakenduse must-have nõudeid. | ||
* Serveris tuleb logida olulisemaid kasutajate poolt klientrakenduses tehtud toiminguid (sisse logimine, konto lukustumine, taski lisamine jmt); | |||
* Kasutaja blokeerimine (ajutine), kui kasutaja on ennast püüdnud autentida vale parooliga enam kui X korda. | |||
<b>Serveri nice-to-have funktsionaalsus</b> | <b>Serveri nice-to-have funktsionaalsus</b> | ||
* Kasutaja poolt sisestatud e-maili kinnitamine (kinnitava e-maili saatmine) kasutaja loomisel. | * Kasutaja poolt sisestatud e-maili kinnitamine (kinnitava e-maili saatmine) kasutaja loomisel. | ||
=== Andmebaasi skeem === | === Andmebaasi skeem === | ||
Esimeses faasis ei realiseeri nö "pehmet kustutamist". Antud lahendus jääb nice-to-have nimekirja. | Esimeses faasis ei realiseeri nö "pehmet kustutamist". Antud lahendus jääb nice-to-have nimekirja. | ||
[[File:AVE_3.0.jpg| | |||
[[File:AVE_3.0.jpg|1000px]] | |||
== Meeskonna XML/XSLT ülesande postitus == | == Meeskonna XML/XSLT ülesande postitus == | ||
Line 149: | Line 153: | ||
Meeskonna Enneaegsed XML faili ülesanne on individuaalsete arvete kuvamine, XML transformatsioonidel aga nende kokkuvõtlik kuvamine nimekirjana ja sobivasse formaati genereerimine, eesmärgiga saada arved trükivormi. XML fail ületab 4 loogilise dimensiooni nõude, sisaldades 6 loogilist dimensioon. Ainult ühes dimensioonis on kasutatud rohkem kui kahte attribuuti korraga. Alamdimensioonides on kasutatud eristamiseks üksikuna esinevaid attribuute, mis on arvete või muu kaudselt seotud andmekogumite kuvamisel ka mõistlik. Olemas on nii XML skeemifail kui ka arvete nimekirja genereerimise transformatsioon andmete muutmiseks HTML formaati ja arvete üldnimekirja kuvamiseks mõeldud arvete genereerimise transformatsioon HTML formaati, mis muudab algset XML faili formaati. Arvete nimekirja kuvamise transformatsioon sisaldab ühte for-each tsüklit struktuuri loova xsl:choose valikuga. Teine, kõik arved genereeriv transformatsioon, on keeleliste konstruktsioonide poolest palju rikkalikum, sisaldades nii mitmetasemelist for-each tsüklit, hargemist ja väljundi kujundamist. Iga arve juures on välja toodud suur valik informatsiooni, seal hulgas arve number, tellimuse number, saaja informatsioon, tähtajainfo, märkused jne. XML faili struktuur on lihtne arvete kogum, mis on terviklik s.t võiks olla reaalses süsteemis kasutamiseks ja on loodud suure põhjalikkusega. Plussina tooksime välja XML koodiga kaasnevate näidiste olemasolu ja selgitavat informatsioon, mis täidab piisava, kuid mitte koormava, dokumentatsiooni rolli. Kood on puhas ja elementide nimetamisel on kasutatud läbivalt samat stiili, mis teeb koodi hästi loetavaks ja arusaadavaks. Meie hinnangul vastab meeskonna Enneaegsed projekti XML osa kõigile esitatud tingimustele. | Meeskonna Enneaegsed XML faili ülesanne on individuaalsete arvete kuvamine, XML transformatsioonidel aga nende kokkuvõtlik kuvamine nimekirjana ja sobivasse formaati genereerimine, eesmärgiga saada arved trükivormi. XML fail ületab 4 loogilise dimensiooni nõude, sisaldades 6 loogilist dimensioon. Ainult ühes dimensioonis on kasutatud rohkem kui kahte attribuuti korraga. Alamdimensioonides on kasutatud eristamiseks üksikuna esinevaid attribuute, mis on arvete või muu kaudselt seotud andmekogumite kuvamisel ka mõistlik. Olemas on nii XML skeemifail kui ka arvete nimekirja genereerimise transformatsioon andmete muutmiseks HTML formaati ja arvete üldnimekirja kuvamiseks mõeldud arvete genereerimise transformatsioon HTML formaati, mis muudab algset XML faili formaati. Arvete nimekirja kuvamise transformatsioon sisaldab ühte for-each tsüklit struktuuri loova xsl:choose valikuga. Teine, kõik arved genereeriv transformatsioon, on keeleliste konstruktsioonide poolest palju rikkalikum, sisaldades nii mitmetasemelist for-each tsüklit, hargemist ja väljundi kujundamist. Iga arve juures on välja toodud suur valik informatsiooni, seal hulgas arve number, tellimuse number, saaja informatsioon, tähtajainfo, märkused jne. XML faili struktuur on lihtne arvete kogum, mis on terviklik s.t võiks olla reaalses süsteemis kasutamiseks ja on loodud suure põhjalikkusega. Plussina tooksime välja XML koodiga kaasnevate näidiste olemasolu ja selgitavat informatsioon, mis täidab piisava, kuid mitte koormava, dokumentatsiooni rolli. Kood on puhas ja elementide nimetamisel on kasutatud läbivalt samat stiili, mis teeb koodi hästi loetavaks ja arusaadavaks. Meie hinnangul vastab meeskonna Enneaegsed projekti XML osa kõigile esitatud tingimustele. | ||
== Meeskonna Veebiteenus & klientrakendus == | |||
29.05.2016 | |||
Veebiteenus ja klientrakendus on realiseeritud ühes solutionis. | |||
Rakenduse valmistamisel on aluseks võetud Mait Poska ja Andres Käveri lahkelt jagatud projektipõhi: [https://github.com/akaver/ASP.NET-BaseApps] [https://github.com/akaver/ASP.NET-WebApiDal] | |||
Rakenduse versioonihaldus toimus GitHub'is [https://github.com/Seramis/ITK_VR2/tree/preSwagger] | |||
'''NB!''' Rakenduse loomisel on katsetatud erinevate tehnoloogiatega. Viimaseks ja õigeks branch'iks jäi 'preSwagger'. | |||
Veebiteenus võimaldab: | |||
*Teenuse pakkumist | |||
*Teenuse kasutajate tuvastamist ning haldamist | |||
*Teenuse kasutajate ja kasutusstatistika üle arve pidamist kasutajate lõikes (http access log serveri poolt, bearing key requesti headeris identifitseerimiseks) | |||
*Teenuse poole pöördumiste arvu piiramist ja piirangute haldamist (IIS QoS manageerimine). | |||
*Teenus toetab mitme kasutaja sisselogimise võimalust. | |||
Teenus on loodud kasutades ASP.NET MVC Web API tehnoloogiat. | |||
Rakenduse testimiseks tuleb käivitada nii WebAPI projekt (serveri pool) kui ka Web projekt (ASP.NET klientrakendus). | |||
Sisselogimiseks on vaikimisi loodud kaks erinevate õigustega kasutajat: | |||
*Admin õigustega: 1@eesti.ee (parool: a) | |||
*Tavakasutaja: 2@eesti.ee (parool: b) | |||
'''Rakendus asub [http://enos.itcollege.ee/~kegipt/VRII/ITK_VR2-preSwagger.zip SIIN].''' | |||
== Retsensioon meeskonnale: [https://wiki.itcollege.ee/index.php/FreeVar FreeVar] == | |||
05.06.2016 | |||
Retsensiooni eesmärk on anda kriitilise analüüsi põhjal koostatud argumenteeritud hinnang kaasõpilaste tööle. Retsensiooni koostamisel hinnati: töö vastavust esitatud tingimustele, programmikoodi loetavust ja ülesehitust ning kommenteeritust ja dokumentatsiooni. | |||
'''Veebirakendus''' | |||
Õppeainest lähtuvalt peab veebiteenus võimaldama: teenuse pakkumist, kasutajate tuvastamist ning haldamist, kasutajate ja kasutusstatistika üle arve pidamist kasutajate lõikes, teenuse poole pöördumiste arvu piiramist ja piirangute haldamist. Samuti peab veebiteenus toetama mitme kasutaja võimalust. | |||
FreeVar teenus võimaldab teenusesse sisse logida (kasutajad tuvastada), uusi kasutajaid luua. Toetatud on ka mitme kasutaja võimalus. Kasutusstatistika ja teenuse poole pöördujate arvu piiramist ja piirangute haldamise kohta paraku ei leidnud. | |||
Veebiteenus on loodud kasutades ASP.NET MVC Web API tehnoloogiat. Andmebaasis on 9 olemit. DTO-sid eraldi realiseeritud ei ole ning sellel otstabel kasutatakse domeeni otse. Seega on kodutöö tingimused täidetud. | |||
WebAPI-s on kasutatud Http-headerid lehendamiseks (vaate jaotuseks), mis on väga kena lähenemine. | |||
Solution on üles ehitatud loogiliselt ning hästi strkutureeritud. Kood on loetav, kuigi vähesel määral kommenteeritud. | |||
Blogi index on realiseeritud. | |||
''Pisimärkused:'' | |||
*Jääb arusaamatuks, miks ViewModel on paigutatud BLL-i alla, mitte ei ole WEB projektis või siis hoopiski eraldi projektina. | |||
*WEB on pandud suhtlema otse BLL-iga, kuna ViewModel asub seal. Tegelikkuses ei peaks klient-rakendus kasutama BLL kihti. (Seda peab kasutama vaid serveri pool) | |||
*Igasugused refereeringud meetoditele võiksid käia läbi NameOf’i, nt actionlink’ides. Praegusel juhul on kasutatud tavalist stringi, mis refactor’dades ei muutu kaasa. | |||
*UOW-s ei ole Repode propertey’d, mis oleks ilmselt koodi kirjutamise lihtsamaks teinud (nt UserInt jmt puhul, mis baasprojektist kaasa tulevad, on need olemas). | |||
'''Klientrakendus''' | |||
Suurem osa kliendirakendusest tundub olevat tegemata. Staatiline leht on olemas aga baas-asjad nagu nt auto lisamine/muutmine on jäänud poolikuks. Autot ei ole võimlaik lisada, kuna dropdown’i (rippmenüü) väärtused puuduvad. Kontrolleris ei ole dropdown mingil viisil väärtustatud (tühi). View template’is on vastav rippmenüü loodud kuid ilma sisuta. Samadel põhjustel ei õnnestu blogi loomine. | |||
BlogPost Controlleris on meetodite kirjeldused kohati sassi läinud, nt create meetodi puhul viitab link hoopis „edit“ meetodile. | |||
Kliendi poolel esineb vigu, nt rakenduses headerile vajutades sorteerimine ei tööta, kuid koodi järgi võiks see nii olla. | |||
'''Kokkuvõte''' | |||
Veebiteenus on koostatud hästi. Eriti võttes arvesse, et teenuse pani püsti vaid üks õppur. Kuid klientrakendus on jäänud poolikuks, mis töömahtu arvestades on arusaadav. Autor on üldiselt aru saanud API teenusest ning oskab seda koostada. |
Latest revision as of 13:11, 5 June 2016
Tiim
- Karina Egipt
- Kärt Palm
- Joonatan Uusväli
- Aleksei Suvorov
Idee
To-do ja ülesannete/tegumite halduse rakendus kooli õppeainete tarvis. Võimaldab märkida kalendrisse tähtaegu, mis on seotud õppeainega ja lisada nende kohta vajalikku infot (eeldatav ajakulu, ülesande maht, õppematerjalid, jne). Keskne online andmebaas - kogu info on hallatav ja nähtav rakenduse kasutajatele. Online funktsionaalsus mis võimaldab "subscribeda" kas teatud õppeainesse, või gruppi. Sellisel juhul ilmuvad kalendrisse ka teiste antud grupis olevate kasutajate lisatud ülesanded, ning info nende kohta.
Analüüs
AVE 3.0 on kodutööde planeerimise rakendus, kuhu registreerutud kasutaja saab lisada õppeaines antud kodutöid, tegevusi lisada neile esitamise tähtaegu ja muud lisainformatsiooni. Sisestatud ülesandeid saab jagada kas kõikide sama ainel osalejatega või siis privaatselt loodud grupis.
AVE 3.0 on edasiarendus eelmisel semestril C# aines loodud rakendusest AVE 2.0. Eelmine ja ühtlasi esimene versioon sisaldas vaid kohaliku kalendri rakenduse funktsionaalsust ning ei võimaldanud ülesandeid kaastudengitega jagada. AVE 3.0 puhul on keskendume registreeritud kasutajate poolt ligipääsetavale online lahendusele. Samuti oleme õppinud vigadest ning muutnud andmebaasi mudelit.
Mõisted
- Task - ülesanne, test, eksam, mille kasutaja kannab kalendrisse ja määrab vähemalt kohustuslikud atribuudid. Task'il saab olla vaid üks tähtaeg;
- Subject - Taske grupeeriv atribuut;
- Group - Taske grupeeriv atribuut, mis on ülem õppeainest (ehk kui grupp on määratud, siis pakutakse antud taski ainult selle grupi liikmetele). Grupp võib eksisteerida ka ilma õppeaineta;
- Subscribe - õppeainega, grupiga või task'iga liitumine, mille tulemusena ilmub vastava aine/grupi task'id kasutaja kalendrisse;
Rakenduse kirjeldus
Rakenduse eesmärgiks on hõlbustada kodutööde planeerimist ja tähtaegade järgimist. Rakendusse saab lisada kodutööde, testide ja eksamite tähtaegu. Sisestatud töid nimetame taskideks. Taskid võivad omakorda sisaldada muud antud ülesandega seotud infot (tähtaeg, kirjeldus, kommentaarid jne).
Rakendus on põhiliselt mõeldud IT Kolledži õppeainete tähtaegade märkimiseks. Sellel eesmärgil on tähtaja juurde võimalik märkida õppeaine Info õppeainete kohta tuleb importida kooli õppeinfosüsteemidest.
Rakenduse kasutamiseks on kohustuslik serveris konto loomine. Anonüümset kasutust ei ole.
Kasutaja saab õppeainele subscribe'ida ja seda tehes saab kasutaja märkida ka oma õppegrupi või õppevormi (näiteks päevaõpe, kaugõpe, õhtuõpe - neid nimetame koondnimetusena “õppeaine versiooniks”). Kasutaja saab luua ka eraldiseisvaid õppetööga seotud gruppe.
Rakendus kuvab kasutajale ka teiste antud aine deklareerinud kasutajate poolt märgitud tähtaegu ja lisainfot nende kohta. Kasutaja võib teiste lisatud taskile kommentaare lisada.
Rakendus koosneb kahest põhilisest osast: veebiklient ja server.
Projekt realiseeritakse kasutades ASP.NET MVC Web API tehnoloogiat.
Esialgne rakenduse ülesehituse skeem:
Klient
Klientprogramm võimaldab kasutajal lisada taske, hallata oma kasutajaprofiili ja vaadata ning lisada endale teiste poolt lisatud taske ja neile lisatud kommentaare.
Veebiklient suhtleb serveriga üle API.
Sisselogimisel küsitakse kasutajalt kasutajanime ja parooli, seejärel üritab rakendus kasutajat autentida. Eduka autentimise korral kuvatakse antud kasutaja töölaud ning sünkroniseeritakse andmed serveriga.
Task'i lisamisel kalendrisse saab sellele lisada erinevat lisainfot (kirjeldus, töö detailsed nõuded, progress jmt). Rakendus teavitab kasutajat, kui task'i täitmise tähtaeg on lähenemas.
Klientrakenduse must-have funktsionaalsus:
- Üldine
- Rakendus peab töötama online režiimis;
- Kasutajate haldus
- Peab olema võimalik kasutajaks registreerida (st kasutajakonto olemasolu on kohustuslik programmi kasutamiseks);
- Kasutaja peab saama sisse logida kasutajanime (st e-maili aadressi) ja parooliga;
- Korraga saab rakendusse olla sisse logitud mitu kasutajat.
- Paroolile peavad rakenduma keerukusnõuded (nt 8 tähemärki, suurtäht, väiketäht, number, sümbol);
- Kasutajatel peavad olema erinevad õiguste tasemed (minimaalselt tavakasutaja ja adminkasutaja/poweruser);
- Tavakasutaja saab hallata ainult iseenda taske ja gruppe;
- Adminkasutaja saab hallata lisaks iseenda taskidele ja gruppidele ka õppeaineid ja õppejõude;
- Klientrakenduse adminkasutaja ei saa hallata teiste kasutajate taske;
- Sisse logitud kasutajale kuvatakse tema taske kalendervaates;
- Kasutaja peab saama registreerida ennast gruppidesse ja erinevatele õppeainetele/kursustele;
- Taskide haldus
- Kasutaja peab saama lisada uut taski;
- Kasutaja poolt lisatud taskid (ja tema poolt subscribe'itud taskid) peavad kajastuma kasutaja kalendris;
- Kasutaja peab saama taski kirjeldusena märkida:
- task'i täitmise tähtaega;
- task'i liiki : ainetöö, essee, kursusetöö, lõputöö, referaat, praktika aruanne, eksam/arvestus, test, muu;
- taskiga seotud õppeaine ettantud nimekirjast (drop-down);
- taskiga seotud gruppi;
- kui taskile on grupp määratud, siis kuvatakse seda taski vaid selle grupi liikmetele;
- soovi korral lisada kommentaariväljale lisainfot, viidet õppematerjalidele jne;
- aega, millal rakendus teavitab kasutajat tähtaja lähenemisest (vabatahtlik, vaikimisi 3 päeva enne);
- taski staatust, st kas task on alustamata, pooleli või lõpetatud;
- Kasutaja peab saama vaadata oma taskide sisu.
- Kasutaja peab saama muuta oma task’ide sisu.
- Kasutaja peab saama oma task'e kustutada.
- Kasutaja peab saama taske märksõna alusel otsida
- Seejuures peab otsing hõlmama kõiki taskidega seotud tekstilisi välju (st pealkiri, kirjeldus, kommentaar, töö liik, grupp, õppeaine, staatus)
- Õppeainete haldus
- Õppeaine peab olema lisatav ja muudetav admin kasutaja (kuid mitte tavakasutaja) poolt
- Õppeained on kasutajale nähtavad
- Õppeainele on võimalik subscribeda (kirjeldatud kasutaja tegevusena)
- Õppejõudude haldus
- Õppejõud on admin kasutaja (kuid mitte tavakasutaja) poolt lisatav ja muudetav
- Õppejõu info (nt kontaktandmed) on kasutajale nähtav
- Õppejõud on seotud õppeainega
- Gruppide haldus
- Uut gruppi saab lisada iga tavakasutaja
- Sellest kasutajast, kes uue grupi lisab, saab vastava grupi omanik
- Gruppi saab muuta või kustutada ainult grupi omanik
- Gruppe saab nime järgi otsida
- Grupi andmeid saavad näha kõik kasutajad (näiteks otsingutulemustes)
- Grupi omanik saab gruppi lisada teisi kasutajaid
- Kui task on seotud mingi grupiga, siis näevad selle taski andmeid ainult vastava grupi liikmed
Klientrakenduse nice-to-have funktsionaalsus:
- Statistika tehtud ülesannete kohta.
- Kasutajakonto loomisel CAPTCHA kasutamine
- Valitud taski liigist lähtuvalt vastava töö nõuete kuvamine (näiteks EIK "Üliõpilaste kirjalike tööde koostamise ja vormistamise juhendi" põhjal)
- Võimalus sünkroniseerida kalendrit mõne välise kalenderrakendusega (Google Calendar, MS Outlook vm).
- Kasutajal parooli reset'imise võimalus (registreerimisel kasutatud e-mailiaadressi abil);
- Grupiga liitumiseks taotluse esitamine. Taotluse peab kinnitama grupi omanik
- Grupist lahkumine
Server
Serveri must-have funktsionaalsus
- Server peab toetama kõiki klientrakenduse must-have nõudeid.
- Serveris tuleb logida olulisemaid kasutajate poolt klientrakenduses tehtud toiminguid (sisse logimine, konto lukustumine, taski lisamine jmt);
- Kasutaja blokeerimine (ajutine), kui kasutaja on ennast püüdnud autentida vale parooliga enam kui X korda.
Serveri nice-to-have funktsionaalsus
- Kasutaja poolt sisestatud e-maili kinnitamine (kinnitava e-maili saatmine) kasutaja loomisel.
Andmebaasi skeem
Esimeses faasis ei realiseeri nö "pehmet kustutamist". Antud lahendus jääb nice-to-have nimekirja.
Meeskonna XML/XSLT ülesande postitus
19.03.2016
Kirjeldus:
- XML fail Taskide andmete edastamiseks (4 loogilist dimensiooni);
- XML faili skeemifail;
- XSL transformatsiooni faili loodud XML failis olevate Taski andmete transformeerimiseks HTML formaati ja XML faili formaadi muutmiseks.
- SkeddlTasksByStatus.xslt - Toob välja kõik etteantud grupi taskid taski staatuse järgi (alustamata, pooleli ja valmis);
- ShowPublicTasks.xslt - Tagastab kõik public Taskid koos kuupäevaga.
.zip fail on kättesaadav SIIT.
XML retsensioon 1
Retsensioon meeskonna Aeg XML failile.
Meeskonna Aeg XML faili eesmärk on edastada andmeid määratlemata ülesannete lahendamiseks kulunud aja kohta. XML faili struktuur ületab 4 loogilise dimensiooni nõude, sisaldades 5 loogilist dimensioon. Kolmel dimensioonil on kasutatud attribuute, kus ei ole piirdutud ainult id attribuudiga, jaotades ajaraportid id alusel nädalasteks arendusperioodideks, mida administraator saab kinnitada või tagasi lükata. Olemas on sobivad XSL transformatsioonid XML faili andmete muutmiseks HTML formaati (Activities) ja XML faili formaadi muutmiseks (Summary) XML formaati kui ka XML skeemifail. Summary transformatsioon sisaldab küll ainult ühte for-loopi, kuid meie hinnangul on see piisav antud lahendusele ja kunstlik kompleksuse juurde lisamine ülevaate puhul lisaväärtust ei tekitaks, kui just ei eraldata paremini kasutajate rolle. Activities transformatsioon on keerulisem, sisaldades for-each tsüklit teise for-each tsükli sees, koos konstruktsioonidega andmete loogiliseks ja terviklikuks esitamiseks. Iga ajaraporti juures on raporti tegija eesnimi, perekonnanimi, osakonnaline kuuluvus ja roll ja tema poolt lisatud sündmuste logid. XML fail valideerus vigadeta w3schools.com XML validaatoris. Kuna arenduskontekst ei ole veel üheselt selge wikilehel leitud info põhjal, siis võib-olla on mõistlik kasutaja roll muuta osakonna alamdimensiooniks ja lisada näiteks projekti juhtimise õiguse jaoks eraldi dimensioon, toetamaks võimaliku mugavusliidese arendamist lisana. Aja ühiku valik võiks olla paindlikum, praegu on tegevuse ühikuks ainult tunnid. Skeemifailis xs:string pikkus võiks olla piiratud andmete esitamise ja raportide kokkuvõtlikusele suunamise eesmärgil maksimaalse väärtusega. Miinusena tooksime välja XML koodi saatva dokumentatsioonilise poole puudulikust: paar selgitavat lauset wikis ja koodi visuaalse väljundi lisamine oleksid meeldivad. Üldiselt kood näeb välja puhas ja elementide nimede valik on hästi läbi mõeldud ja stiil pidev. Meie hinnangul vastab meeskonna Aeg projekti XML osa kõigile esitatud tingimustele.
XML retsensioon 2
Retsensioon meeskonna Enneaegsed XML failile.
Meeskonna Enneaegsed XML faili ülesanne on individuaalsete arvete kuvamine, XML transformatsioonidel aga nende kokkuvõtlik kuvamine nimekirjana ja sobivasse formaati genereerimine, eesmärgiga saada arved trükivormi. XML fail ületab 4 loogilise dimensiooni nõude, sisaldades 6 loogilist dimensioon. Ainult ühes dimensioonis on kasutatud rohkem kui kahte attribuuti korraga. Alamdimensioonides on kasutatud eristamiseks üksikuna esinevaid attribuute, mis on arvete või muu kaudselt seotud andmekogumite kuvamisel ka mõistlik. Olemas on nii XML skeemifail kui ka arvete nimekirja genereerimise transformatsioon andmete muutmiseks HTML formaati ja arvete üldnimekirja kuvamiseks mõeldud arvete genereerimise transformatsioon HTML formaati, mis muudab algset XML faili formaati. Arvete nimekirja kuvamise transformatsioon sisaldab ühte for-each tsüklit struktuuri loova xsl:choose valikuga. Teine, kõik arved genereeriv transformatsioon, on keeleliste konstruktsioonide poolest palju rikkalikum, sisaldades nii mitmetasemelist for-each tsüklit, hargemist ja väljundi kujundamist. Iga arve juures on välja toodud suur valik informatsiooni, seal hulgas arve number, tellimuse number, saaja informatsioon, tähtajainfo, märkused jne. XML faili struktuur on lihtne arvete kogum, mis on terviklik s.t võiks olla reaalses süsteemis kasutamiseks ja on loodud suure põhjalikkusega. Plussina tooksime välja XML koodiga kaasnevate näidiste olemasolu ja selgitavat informatsioon, mis täidab piisava, kuid mitte koormava, dokumentatsiooni rolli. Kood on puhas ja elementide nimetamisel on kasutatud läbivalt samat stiili, mis teeb koodi hästi loetavaks ja arusaadavaks. Meie hinnangul vastab meeskonna Enneaegsed projekti XML osa kõigile esitatud tingimustele.
Meeskonna Veebiteenus & klientrakendus
29.05.2016
Veebiteenus ja klientrakendus on realiseeritud ühes solutionis. Rakenduse valmistamisel on aluseks võetud Mait Poska ja Andres Käveri lahkelt jagatud projektipõhi: [1] [2]
Rakenduse versioonihaldus toimus GitHub'is [3] NB! Rakenduse loomisel on katsetatud erinevate tehnoloogiatega. Viimaseks ja õigeks branch'iks jäi 'preSwagger'.
Veebiteenus võimaldab:
- Teenuse pakkumist
- Teenuse kasutajate tuvastamist ning haldamist
- Teenuse kasutajate ja kasutusstatistika üle arve pidamist kasutajate lõikes (http access log serveri poolt, bearing key requesti headeris identifitseerimiseks)
- Teenuse poole pöördumiste arvu piiramist ja piirangute haldamist (IIS QoS manageerimine).
- Teenus toetab mitme kasutaja sisselogimise võimalust.
Teenus on loodud kasutades ASP.NET MVC Web API tehnoloogiat.
Rakenduse testimiseks tuleb käivitada nii WebAPI projekt (serveri pool) kui ka Web projekt (ASP.NET klientrakendus). Sisselogimiseks on vaikimisi loodud kaks erinevate õigustega kasutajat:
- Admin õigustega: 1@eesti.ee (parool: a)
- Tavakasutaja: 2@eesti.ee (parool: b)
Rakendus asub SIIN.
Retsensioon meeskonnale: FreeVar
05.06.2016
Retsensiooni eesmärk on anda kriitilise analüüsi põhjal koostatud argumenteeritud hinnang kaasõpilaste tööle. Retsensiooni koostamisel hinnati: töö vastavust esitatud tingimustele, programmikoodi loetavust ja ülesehitust ning kommenteeritust ja dokumentatsiooni.
Veebirakendus
Õppeainest lähtuvalt peab veebiteenus võimaldama: teenuse pakkumist, kasutajate tuvastamist ning haldamist, kasutajate ja kasutusstatistika üle arve pidamist kasutajate lõikes, teenuse poole pöördumiste arvu piiramist ja piirangute haldamist. Samuti peab veebiteenus toetama mitme kasutaja võimalust.
FreeVar teenus võimaldab teenusesse sisse logida (kasutajad tuvastada), uusi kasutajaid luua. Toetatud on ka mitme kasutaja võimalus. Kasutusstatistika ja teenuse poole pöördujate arvu piiramist ja piirangute haldamise kohta paraku ei leidnud.
Veebiteenus on loodud kasutades ASP.NET MVC Web API tehnoloogiat. Andmebaasis on 9 olemit. DTO-sid eraldi realiseeritud ei ole ning sellel otstabel kasutatakse domeeni otse. Seega on kodutöö tingimused täidetud.
WebAPI-s on kasutatud Http-headerid lehendamiseks (vaate jaotuseks), mis on väga kena lähenemine.
Solution on üles ehitatud loogiliselt ning hästi strkutureeritud. Kood on loetav, kuigi vähesel määral kommenteeritud.
Blogi index on realiseeritud.
Pisimärkused:
- Jääb arusaamatuks, miks ViewModel on paigutatud BLL-i alla, mitte ei ole WEB projektis või siis hoopiski eraldi projektina.
- WEB on pandud suhtlema otse BLL-iga, kuna ViewModel asub seal. Tegelikkuses ei peaks klient-rakendus kasutama BLL kihti. (Seda peab kasutama vaid serveri pool)
- Igasugused refereeringud meetoditele võiksid käia läbi NameOf’i, nt actionlink’ides. Praegusel juhul on kasutatud tavalist stringi, mis refactor’dades ei muutu kaasa.
- UOW-s ei ole Repode propertey’d, mis oleks ilmselt koodi kirjutamise lihtsamaks teinud (nt UserInt jmt puhul, mis baasprojektist kaasa tulevad, on need olemas).
Klientrakendus
Suurem osa kliendirakendusest tundub olevat tegemata. Staatiline leht on olemas aga baas-asjad nagu nt auto lisamine/muutmine on jäänud poolikuks. Autot ei ole võimlaik lisada, kuna dropdown’i (rippmenüü) väärtused puuduvad. Kontrolleris ei ole dropdown mingil viisil väärtustatud (tühi). View template’is on vastav rippmenüü loodud kuid ilma sisuta. Samadel põhjustel ei õnnestu blogi loomine.
BlogPost Controlleris on meetodite kirjeldused kohati sassi läinud, nt create meetodi puhul viitab link hoopis „edit“ meetodile.
Kliendi poolel esineb vigu, nt rakenduses headerile vajutades sorteerimine ei tööta, kuid koodi järgi võiks see nii olla.
Kokkuvõte
Veebiteenus on koostatud hästi. Eriti võttes arvesse, et teenuse pani püsti vaid üks õppur. Kuid klientrakendus on jäänud poolikuks, mis töömahtu arvestades on arusaadav. Autor on üldiselt aru saanud API teenusest ning oskab seda koostada.