HMR: Difference between revisions
(18 intermediate revisions by 2 users not shown) | |||
Line 623: | Line 623: | ||
=Veebiteenus ja klientrakendus= | =Veebiteenus ja klientrakendus= | ||
Anname väikese sissejuhatuse NutiHoone API-st ja klientrakendusest. | Anname väikese sissejuhatuse NutiHoone API-st ja klientrakendusest. Teenuse tehnoloogiaks on kasutatud RESTi ja ASP.NET Web API-t ning rakendus on tehtud ASP.NET MVC rakendusena. | ||
Tegemist on rakendusega mis laseb inimestel mingit hoonet hallata. Samuti annab rakendus aimu hoonet iseloomustavatest parameetritest. Lühidalt on arenduse idee selles, et maja ja tema kasutaja oleks teadlik maja olukorrast. | Tegemist on rakendusega mis laseb inimestel mingit hoonet hallata. Samuti annab rakendus aimu hoonet iseloomustavatest parameetritest. Lühidalt on arenduse idee selles, et maja ja tema kasutaja oleks teadlik maja olukorrast. | ||
Line 634: | Line 634: | ||
Rakenduse koodi tutvustuseks tahaks ära märkida, et seal ei kasutata eraldi andmebaasi, vaid kõik andmed asuvad api andmebaasis. Rakenduse projekti ülesehitusest võib vähesel süvenemisel taoline mulje jääda, aga selline rakenduse lahenduse struktuur tulenes sellest, et kasutasime seal Entity Frameworki kontrollerite ja vaadete loomiseks. See on tunduvalt mugavam moodus kui vaateid manuaalselt luua. | Rakenduse koodi tutvustuseks tahaks ära märkida, et seal ei kasutata eraldi andmebaasi, vaid kõik andmed asuvad api andmebaasis. Rakenduse projekti ülesehitusest võib vähesel süvenemisel taoline mulje jääda, aga selline rakenduse lahenduse struktuur tulenes sellest, et kasutasime seal Entity Frameworki kontrollerite ja vaadete loomiseks. See on tunduvalt mugavam moodus kui vaateid manuaalselt luua. | ||
Api | Sensorite andmete lugemiseks on loodud moodul RawDataCollectingLayer(RDCL). | ||
Arenduse ja katsetuste käigus loodi kaks veidi erinevat versiooni. Esimene neist paikeneb Api solutioni koosseisus ja kasutab loetud sensorandmete sisestamiseks baasi UOW liidest. Teine versioon on täiesti eraldiseisev solution, mis kasutab andmebaasi andmete lisamiseks Api teenust. Andmete edastus Api-le käib üle käsu POST, Api ise lisab andmed baasi. See versioon ei pea "teadama" midagi andmebaasist vaid oluline on vaid Api url. | |||
Üldiselt on tegemist vahendiga, mis kogub reaalselt andmeid internetis paiknevas andevahetuskataloogist ja lisab need Sensordata olemi tabelisse, mida api teenus saab edukalt välja kuvada. Tegemist on siis virtuaalselt loodud olukorraga, kus majas asuvate andurite näitajad ilmuvad rakenduses vaatamiseks. Selleks, et need andmed ilmuksid tuleb esimene RDCL versioon panna startup projektiks ning see siis käivitada ja lasta sel veidi aega joosta. Teise versiooni puhul piisab solutioni kompileerimisest ja käivitamiset. Vajadusel peab muutma ainult api urli. | |||
RDCL on püütud luua selliselt, et oleks võimalik kergesti luua erinevat tüüpi ühendusi. Praegu on kasutusel xml fali lugeja. Samas peaks saama tekitada lihtsalt ka TCP Klient/Server süsteemi repository. | |||
Kahjuks tuleb lõpetuseks nentida, et käesolevaks kuupäevaks (24.05.2015) ei ole me api ega rakendus veel täielikul määral valmis. Meie meeskond plaanib projekte oluliselt kaitsmise ajaks veel täiendada. Aga usume, et hektel valmisolev annab ka aimu, et vajalikud tehnoloogiad on rakendatud ja korralik toorik on olemas. | Kahjuks tuleb lõpetuseks nentida, et käesolevaks kuupäevaks (24.05.2015) ei ole me api ega rakendus veel täielikul määral valmis. Meie meeskond plaanib projekte oluliselt kaitsmise ajaks veel täiendada. Aga usume, et hektel valmisolev annab ka aimu, et vajalikud tehnoloogiad on rakendatud ja korralik toorik on olemas. | ||
Projektides on kasutatud reposid, liideseid, UOW-d, url-id on config faili pandud. Sisselogimine on samuti projektis üks töötav osa, parool krüpteeritud kujul. Api poolel kontrollerid nõuavad autoriseerimist. Lisaks kasutatud migratsioone. Äriloogika ja andmebaasi kiht on eraldi viidud. Lisaks api poolel kasutame vahekihti BLL, et peita rakendusele äriloogikat. Lisaks kasutame vaatemudeleid, et kuvada vaadetesse dropdown liste. | |||
Link API ja rakenduse zip failidele: http://enos.itcollege.ee/~hluts/vr2/ | Link API ja rakenduse zip failidele: http://enos.itcollege.ee/~hluts/vr2/ | ||
RDCL/Andmete koguja http://enos.itcollege.ee/~mkabanen/vr2/ | |||
= Retsensioonid veebiteenusele ja klientrakendusele = | |||
Meie grupp valis retsenseeirmiseks grupi KRTT (https://wiki.itcollege.ee/index.php/KRTT#Veebiteenus_ja_klientrakendus) töö. Retsensioon on kahes osas, kõigepealt teenuse ja seejärel rakenduse retsensioon. | |||
== Veebiteenuse retsensioon == | |||
''' Sissejuhatus ''' | |||
Grupi KRTT veebiteenus oli realiseeritud ASP.NET MVC Web API-na ning kasutatud oli REST teenust ning andmete käitlemiseks kasutati JSONi formaati. Teenuse puhul oli kasutatud töö spetsifikatsioonis ettenähtud tehnoloogiaid ning arendusmustreid. Töös oli kasutatud kenasti UOW mustrit, s.t päringud ei käinud otse andmebaasi vastu. Samuti oli andmekihis kasutatud interface, nii nagu oli projekti kirjelduses ette nähtud. | |||
Projektis oli kasutatud code first lähenemist ning andmebaasi genereerimiseks kasutati Entity Frameworki. Et API ei annaks välja ebavajalikku infot oli projektis kenasti realiseeritud DTO (Data Transfer Object) vahekiht. | |||
Töös oli kasutatud code first lähenemist ning andmebaasi genereerimiseks on kasutatud Entity Frameworki. Samuti on töös kasutatud nõutul määral olemeid, arvestamata seejuures sisse autentimise toimimiseks vajalike olemite arvust. | |||
''' Projekti üldiste nõuete täidetus ''' | |||
Tulles nüüd detailide juurde siis alustuseks tuleb ära mainida, et grupi KRTT veebiteenus läks meie meeskonna liikmete arvutites ilma probleemideta tööle. | |||
Tulles nüüd üldisemate teenuse poolele esitatud nõuete juurde, siis kõigepealt mainime ära, et teenus toimib kenasti. Projektis oli teenusele esitatud turvatuse nõue, vaatlusaluse projekti puhul on see nõue täidetud. | |||
Samas oli teenuse puhul väike soovitus, et erinevateks toiminguteks oleks vastav haldusliides. Mingit rakendust kahjuks haldamiseks polnud. See tõstatas mõningaid küsimusi, nimelt vaikimisi oli õppejõu Andres Käveri näidiskoodis olemas MVC rakenduse kujul kasutajahalduse rakendus. Kahjuks need põhjused, miks antud rakendusest otsustati veebiteenuses loobuda ei ole meile teadlikud. Väikese märkusena võiks siiski öelda, et rakenduse olemasolu annaks API kasutamiskogemusele palju juurde. | |||
Ilmselt siis kogu kasutajahaldus on jäetud otse andmebaasi vastu käima, see kindlasti pole hea ega turvaline praktika. Kui grupil on huvi antud projekti veel edasi arendada, siis kindlasti soovitaks luua mingi API poolse haldamise rakenduse. | |||
Teine nõue projektis oli see, et teenus peaks pidama arvet kasutajate ning kasutusstatistika üle kasutajate lõikes. See nõue käesolevas projektis polnud täidetud, vähemalt meie grupp ei leidnud nii teenuse kui rakenduse väljundis sellele viiteid. Samuti ei leidnud me ka koodis mingeid kohti, mis viitaksid sellele, et antud nõue oleks implementeeritud. | |||
Projekti nõudeks oli ka teenuse poole pöördumiste arvu piiramine ning piirangute haldamine. See funktsionaalsus oli samuti implementeerimata. Vähemalt meie grupp selle kohta projektis viiteid ei leidnud. | |||
''' Üldine lahenduse (solution) ülesehitus ''' | |||
Lahendus on kenasti struktureeritud ja jaotatud eri projektide vahel. See muudab lahendusest aru saamine väga mugavamaks. Kasutatud on levinud ülesehtist, olemid on omaette projektis. Andmebaasi loogika on omaette projektis ning samuti ka API. Kuna meie grupp kasutas oma projektis sarnast loogikat, siis oli väga kerge projektis orienteeruda. | |||
Väikese märkusena võiks lisada, et meie soovitus oleks olemite projektile (Domain) teha spetsiaalne kaust, kus on kirjas projekti olemid. Praegu olid nad otse lahenduses, hiljem kui peaks tekkima vajadus lahendust laiendada, siis erinevate olemite kirjeldamine projekti üldises juurkataloogis võib põhjustada ebamugavusi. | |||
''' Koodistiil ''' | |||
Koodi puhul tuleb nentida, et see on kenasti vormistatud ja kergesti jälgitav. Samuti on olemite atribuutide ja meetodite nimed nimetatud nõnda, et nendest on võimalik kogu atribuudi ja meetodi sisu välja lugeda. Sellest tuleneval on koodi lugemine väga mugav ning sellest aru saamine väga intuitiivne. | |||
Mainime ära, et käesoleva töö analüüsijatele antud lahendus meeldib. Selle asemel et kirjutada väga ebaloogiliste muutujate nimedega koodi (näiteks string x ning int y) ning seejärel kommentaarides täpsustades muutujate olemust annavad käesolevas koodis olevad muutujate ning meetodite nimetused kohe vajaliku info kätte. Meie grupp pooldab väga taolist lahendust, et kood kirjutatakse nõnda, et see kommenteerib end niiöelda ise ja ohtraid kommentaare pole tarvis. | |||
''' Üldised kommentaarid ''' | |||
Meie meeskonnale meeldis fakt, et mudelites oli kasutatud enumeid. Kuigi mainiksime siin ära väikese kriitikana, et võibolla oleks ka nende valikuväljade puhul kasutada erinevaid objekte, et neid näiteks hiljem kasutajaliidese kaudu muuta ning hallata. Samas me ka ei kritiseeri nende kasutamist, kindlasti nad lühendasid arendamise aega. | |||
Rääkides API projektist (WebApiApp), siis grupi kiituseks tuleb öelda, et seal on kontrollerite meetodid kenasti kommenteeritud. Samas kõrvalmärkusena võib öelda, et meetodid on nõnda nimetatud, et need annavad kohe aimu meetodi iseloomust. Samas plusspunktid nende eest. | |||
''' Kokkuvõte ''' | |||
Kokkuvõtteks võib öelda, et API tehnilise poole pealt pole ühtegi negatiivset sõna. Kõik toimib kenasti. Kood on kirjutatud arusaadavalt, samuti on lahendus loogiliselt struktureeritud. | |||
Miinuspoole pealt peab mainima, et kahjuks täit rakenduse funktsionaalsust (näiteks kasutusstatistika) pole hetkel veel realiseeritud. | |||
== Klientrakenduse retsensioon == | |||
''' Sissejuhatus ''' | |||
Grupi KRTT rakendus on realiseeritud Windows WPF rakendusena. Tuleb tunnistada, et meie grupile oli valik vägagi üllatav, ei osanud seda oodata. | |||
Meie hinnangul pole antud valik selles mõttes õnnestunud, et WPF puhul tuleb väga suur osa kasutajaliidesest ise käsitsi kirjutada. Antud valikuga kaasnes ilmselt väga palju ajakulu. | |||
Samas kui valida projektis ASP NET MVC projekt, siis seal oleks Visual Studio ise väga palju käsitööd ära teinud (CRUD vaated, Bootstrap, vormikontroll ja palju muud). Võibolla oli asi tingitud sellest, et olles äsja tulnud C# ainest oli WPF rakenduse tegemise kogemus olemas ja seega otsustas grupp KRTT panustada enda tugevatele külgedele. | |||
''' Rakenduse testimine ''' | |||
Lühidalt öeldes tuleb nentida, et rakenduse kasutajakogemus ei olnud väga meeldiv. Kasutajaliides polnud kõige kaunim, aga see pole meie hinnangul kõige suurem miinus. Peamine probleem seisnes selles, et WPF rakendus kippus kokku jooksma. See on väga suur miinus. | |||
Toome ühe kasutusjuhtumi analüüsi, kus rakendus lakkas töötamast. Üritades end rakenduusega registreeruda ilmneb tõsiasi, et peale vajalike andmete sisestamist mingit registreerumist ei toimu ning sisse logida pole võimalik. | |||
Negatiivne on ka see aspekt, et peale seda kaob menüüs ära “Register” nupp, mis võimaldaks tekitada teise kasutaja, igaks juhuks testimaks, et äkki siis logimine õnnestub. Samuti puudub võimalus andmete muutmiseks. Kui on soov “Register” nupp tagasi saada siis tuleb selleks kas vajutada “Menu” või “Home” nupule. Tegemist ei ole hea kasutajakogemusega ja soovitaks seetõttu kasutajaliidese paremini läbi mõelda. | |||
Kasutaja registreerimise vormi kohta oleks märkuseks, et salasõna väljadel ei ole hea kuvada sisestatud salasõna. Sobilik oleks kasutada standartset lahendust, kus sisestatud salasõna kuvatakse täppidena. | |||
Viga ilmnes ka siis, et kui proovida eelnevalt Kui proovida eelnevalt sisestatud kasutajaga rakendusse siseneda, siis on tulemuseks exception, mida ei käsitleta, s.t koodis puudub „try … catch“ plokk. Viimane on aga veatundliku koodi puhul teatavasti oluline. Kasutaja seisukohast ei saa seega mitte mingisugust informatsiooni selle kohta, mis valesti läks. | |||
Samamoodi kukub rakendus kokku kui vajutada nupule “Load cars”, sel puhul samuti ei kuvata mingisugust veateadet. Võib vaid oletada, mis on selle vea põhjuseks, kas näiteks rakendus ei saa teenusega ühendust või on mingi muu probleem. Igal juhul oleks hea sellest probleemist kasutajat informeerida. | |||
Siinkohal on taaskord näha kui oluline on strateegiline otsus rakenduse tüübi valiku osas. MVC rakenduses oleks väga palju veahaldusest ära tehtud. See valik oleks tõenäoliselt väga palju säästnud grupi KRTT aega. Samas tuleb nentida, et ilsmelt pole grupp KRTT vigadesse väga kergekäoliselt suhtunud, vaid on proovinud neid ka lahendada. Sellele viitavad mitmed koodi sisse jäänud break pointid. | |||
''' Soovitused valminud WPF rakenduse parendamiseks ''' | |||
Meie grupi soovitus oleks veidi mõelda üldisematele kujundusreeglitele. Hetkel on kasutajaliidese pool väga minimalistlik ja raskesti hoomatav. | |||
Hetkel on suur valge ala “MainWindow” keskel, mis koodianalüüsist lähtudes tundub olevat auto pildi kuvamiseks, seda võib aru saada tutvudes faili Cars.xaml sisuga. Samas kui ühtegi autot valitud pole, siis jääb üldmulje vägagi tühjaks. | |||
Meie hinnangul puuduvad WPF rakenduses kasutajaliideses kohad kõikide veebiteenuse olemite manipuleerimiseks. Näiteks meie grupile jäi selgusetuks kuidas sisestada ettevõtet (olem Firm), rendilepingut, ülevaatust või autovarustust. | |||
Samas me ei saa väita, et seda funktsionaalust pole olemas. Põhjus seisneb selles, et me ei suutnud WPF rakenduses ennast sisse logida ja rakendust proovida. Meie arvamus põhineb puhtalt koodianalüüsil. Me ei leidnud neid teenuste, põhiolemite ega vaatemudelite alt. | |||
''' Koodistiil ''' | |||
Koodistiili kohta pole tegelikult mitte midagi halba öelda. Kood on sarnaselt teenuse koodile kirjutatud väga puhtalt ja mõistetavalt, samuti on kood kenasti vormindatud. Samas on rakendusel väga palju bugisi, seetõttu hea koodistiil ei kaalu üles rakenduse bugisid. | |||
''' Kokkuvõte ''' | |||
Kokkuvõtteks võib öelda, et WPF rakenduse arendamisega on mõistlik veel tegeleda. Kasutamisel ilmnes väga palju vigu ja seega me ei saanud kogu funktsionaalust testida. | |||
Meie poolne soovitus oleks, et grupp KRTT kaaluks näiteks mõne spetsiaalse veebiliidese arendamist, miks mitte näiteks ASP NET MVC rakendus. Seal võtab raamistik rakenduse baasfunktsionaalsuse osas väga palju tööd enda kanda ning arendajatel jääb aega eriarendustega tegelemiseks. | |||
= Logi = | = Logi = | ||
Line 652: | Line 753: | ||
== 07.04.15 - Analüüsi esitamine == | == 07.04.15 - Analüüsi esitamine == | ||
Analüüs üles laetud. | Analüüs üles laetud. | ||
== 25.04.15 - Hackathon == | |||
Tulemus oli erinevatel põhjustel suhteliselt kesine. Positiivne oli see, et kõigil grupi liikmetel oli lõpuks olemas peaaegu ühtne versioon projektist, mis tõsi küll, mõnel ei kompileerunud. | |||
== 24.05.15 - Teenus ja rakendus == | |||
Teenus ja rakendus enam-vähem(pigem vähem) valmis ning konstruktiivse kriitika jaoks avalikustatud. | |||
== 30.05.15 - Retsensioonid == | |||
Retsensioonid Veebiteenusele ja klientrakendusele valmis. |
Latest revision as of 20:50, 30 May 2015
Idee
NutiHoone
Meeskond HMR
- Harles Luts
- Mattiko Kabanen
- Ranek Runthal
XML formaadis admeedastus
XML andmefail
<?xml version="1.0" encoding="utf-8" ?>
<Solarsystem>
<TableHeader>
<Column id="1" units="">
<Name lang="eng"><![CDATA[Name]]></Name>
<Name lang="est"><![CDATA[Nimi]]></Name>
</Column>
<Column id="2" units="AU">
<Name lang="eng"><![CDATA[Distance]]></Name>
<Name lang="est"><![CDATA[Kaugus]]></Name>
</Column>
<Column id="3" units="bar">
<Name lang="eng"><![CDATA[Pressure on surface]]></Name>
<Name lang="est"><![CDATA[Rõhk pinnal]]></Name>
</Column>
<Column id="4" units="">
<Name lang="eng"><![CDATA[Components of atmosphere]]></Name>
<Name lang="est"><![CDATA[Atmosfääri peamised komponendid]]></Name>
</Column>
<Column id="5" units="">
<Name lang="eng"><![CDATA[More information]]></Name>
<Name lang="est"><![CDATA[Rohem teavet]]></Name>
</Column>
</TableHeader>
<Planets count="8">
<Planet mass="0.055" unit="em" distfromsun="0.46" dunits="AU">
<Test>
<![CDATA[No see on test!!!]]>
</Test>
<Name lang="eng">
<![CDATA[Mercury]]>
</Name>
<Name lang="est">
<![CDATA[Merkuur]]>
</Name>
<Atmosphere surfpress="0.001" punit="picobar">
<Component percent="42" >
<Name lang="eng"><![CDATA[Oxygen]]></Name>
<Name lang="est"> <![CDATA[Hapnik]]></Name>
<ChemElem atoms="2">O</ChemElem>
</Component>
<Component percent="29">
<Name lang="eng">
<![CDATA[Sodium]]></Name>
<Name lang="est"><![CDATA[Naatrium]]></Name>
<ChemElem>Na</ChemElem>
</Component>
<Component percent="22">
<Name lang="eng"><![CDATA[Hydrogen]]></Name>
<Name lang="est"><![CDATA[Vesinik]]></Name>
<ChemElem atoms="2">H</ChemElem>
</Component>
</Atmosphere>
<MoreInfo type="weblink">
<![CDATA[http://nssdc.gsfc.nasa.gov/planetary/factsheet/mercuryfact.html]]>
</MoreInfo>
</Planet>
<!-- ........................................................................... -->
<Planet mass="0.815" unit="em" distfromsun="0.7" dunits="AU">
<Name lang="eng">
<![CDATA[Venus]]>
</Name>
<Name lang="est">
<![CDATA[Veenus]]>
</Name>
<Atmosphere surfpress="92" punit="bar">
<Component percent="96.5">
<Name lang="eng"><![CDATA[Carbon Dioxide]]></Name>
<Name lang="est"> <![CDATA[Süsinik dioksiid]]></Name>
<ChemElem atoms="1">C</ChemElem>
<ChemElem atoms="2">O</ChemElem>
</Component>
<Component percent="3.5">
<Name lang="est"><![CDATA[Lämmasik]]></Name>
<Name lang="eng"><![CDATA[Nitrogen]]></Name>
<ChemElem atoms="2">N</ChemElem>
</Component>
</Atmosphere>
<MoreInfo type="weblink">
<![CDATA[http://nssdc.gsfc.nasa.gov/planetary/factsheet/venusfact.html]]>
</MoreInfo>
</Planet>
<!-- ........................................................................... -->
<Planet mass="1.0" unit="em" distfromsun="1.0" dunits="AU">
<Name lang="eng">
<![CDATA[Earth]]>
</Name>
<Name lang="est">
<![CDATA[Maa]]>
</Name>
<Atmosphere surfpress="1014" punit="mbar">
<Component percent="78.08">
<Name lang="eng"><![CDATA[Nitrogen]]></Name>
<Name lang="est"> <![CDATA[Lämmastik]]></Name>
<ChemElem atoms="2">N</ChemElem>
</Component>
<Component percent="20.95">
<Name lang="est">
<![CDATA[Hapnik]]></Name>
<Name lang="eng"><![CDATA[Oxygen]]></Name>
<ChemElem atoms="2">O</ChemElem>
</Component>
</Atmosphere>
<MoreInfo type="weblink">
<![CDATA[http://nssdc.gsfc.nasa.gov/planetary/factsheet/earthfact.html]]>
</MoreInfo>
</Planet>
<!-- ........................................................................... -->
<Planet mass="0.64174" unit="em" distfromsun="1.5" dunits="AU">
<Name lang="eng">
<![CDATA[Mars]]>
</Name>
<Name lang="est">
<![CDATA[Marss]]>
</Name>
<Atmosphere surfpress="1014" punit="mbar">
<Component percent="95.32">
<Name lang="eng"><![CDATA[Carbon Dioxide]]></Name>
<Name lang="est"> <![CDATA[Süsinik dioksiid]]></Name>
<ChemElem atoms="1">C</ChemElem>
<ChemElem atoms="2">O</ChemElem>
</Component>
<Component percent="2.7">
<Name lang="est"><![CDATA[Lämmastik]]></Name>
<Name lang="eng"><![CDATA[Nitrogen]]></Name>
<ChemElem atoms="2">N</ChemElem>
</Component>
</Atmosphere>
<MoreInfo type="weblink">
<![CDATA[http://nssdc.gsfc.nasa.gov/planetary/factsheet/marsfact.html]]>
</MoreInfo>
</Planet>
<!-- ........................................................................... -->
<Planet mass="318" unit="em" distfromsun="5.2" dunits="AU">
<Name lang="eng">
<![CDATA[Jupiter]]>
</Name>
<Name lang="est">
<![CDATA[Jupiter]]>
</Name>
<Atmosphere surfpress="1000" punit="bar">
<Component percent="89.8">
<Name lang="eng"><![CDATA[Molecular Hydorgen]]></Name>
<Name lang="est"> <![CDATA[Molekulaarne vesinik]]></Name>
<ChemElem atoms="2">H</ChemElem>
</Component>
<Component percent="10.2">
<Name lang="est"><![CDATA[Heelium]]></Name>
<Name lang="eng"><![CDATA[Helium]]></Name>
<ChemElem atoms="1">He</ChemElem>
</Component>
</Atmosphere>
<MoreInfo type="weblink">
<![CDATA[http://nssdc.gsfc.nasa.gov/planetary/factsheet/jupiterfact.html]]>
</MoreInfo>
</Planet>
<!-- ........................................................................... -->
<Planet mass="568" unit="em" distfromsun="9.5" dunits="AU">
<Name lang="eng">
<![CDATA[Saturn]]>
</Name>
<Name lang="est">
<![CDATA[Saturn]]>
</Name>
<Atmosphere surfpress="1000" punit="bar">
<Component percent="96.3">
<Name lang="eng"><![CDATA[Molecular Hydorgen]]></Name>
<Name lang="est"> <![CDATA[Molekulaarne vesinik]]></Name>
<ChemElem atoms="2">H</ChemElem>
</Component>
<Component percent="3.25">
<Name lang="est"><![CDATA[Heelium]]></Name>
<Name lang="eng"><![CDATA[Helium]]></Name>
<ChemElem atoms="1">He</ChemElem>
</Component>
</Atmosphere>
<MoreInfo type="weblink">
<![CDATA[http://nssdc.gsfc.nasa.gov/planetary/factsheet/saturnfact.html]]>
</MoreInfo>
</Planet>
<!-- ........................................................................... -->
<Planet mass="87" unit="em" distfromsun="19.2" dunits="AU">
<Name lang="eng">
<![CDATA[Uranus]]>
</Name>
<Name lang="est">
<![CDATA[Uraan]]>
</Name>
<Atmosphere surfpress="1000" punit="bar">
<Component percent="82.5">
<Name lang="eng"><![CDATA[Molecular Hydorgen]]></Name>
<Name lang="est"> <![CDATA[Molekulaarne vesinik]]></Name>
<ChemElem atoms="2">H</ChemElem>
</Component>
<Component percent="15.2">
<Name lang="est"><![CDATA[Heelium]]></Name>
<Name lang="eng"><![CDATA[Helium]]></Name>
<ChemElem atoms="1">He</ChemElem>
</Component>
</Atmosphere>
<MoreInfo type="weblink">
<![CDATA[http://nssdc.gsfc.nasa.gov/planetary/factsheet/uranusfact.html]]>
</MoreInfo>
</Planet>
<!-- ........................................................................... -->
<Planet mass="568" unit="em" distfromsun="30.1" dunits="AU">
<Name lang="eng">
<![CDATA[Neptun]]>
</Name>
<Name lang="est">
<![CDATA[Neptuun]]>
</Name>
<Atmosphere surfpress="1000" punit="bar">
<Component percent="80.0">
<Name lang="eng"><![CDATA[Molecular Hydorgen]]></Name>
<Name lang="est"> <![CDATA[Molekulaarne vesinik]]></Name>
<ChemElem atoms="2">H</ChemElem>
</Component>
<Component percent="19.0">
<Name lang="est"><![CDATA[Heelium]]></Name>
<Name lang="eng"><![CDATA[Helium]]></Name>
<ChemElem atoms="1">He</ChemElem>
</Component>
</Atmosphere>
<MoreInfo type="weblink">
<![CDATA[http://nssdc.gsfc.nasa.gov/planetary/factsheet/neptunefact.html]]>
</MoreInfo>
</Planet>
<!-- ........................................................................... -->
</Planets>
<Asteroids>
<Asteroid>
</Asteroid>
</Asteroids>
</Solarsystem>
XML skeemifail
<?xml version="1.0" encoding="utf-8"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Solarsystem">
<xs:complexType>
<xs:sequence>
<xs:element name="TableHeader">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Column">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Name">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="id" type="xs:unsignedInt" use="required" />
<xs:attribute name="units" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Planets">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Planet">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="Test" type="xs:string" />
<xs:element maxOccurs="unbounded" name="Name">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name="Atmosphere">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Component">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Name">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="lang" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element maxOccurs="unbounded" name="ChemElem">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="atoms" type="xs:unsignedInt" use="optional" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="percent" type="xs:decimal" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="surfpress" type="xs:decimal" use="required" />
<xs:attribute name="punit" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
<xs:element name="MoreInfo">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="type" type="xs:string" use="required" />
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="mass" type="xs:decimal" use="required" />
<xs:attribute name="unit" type="xs:string" use="required" />
<xs:attribute name="distfromsun" type="xs:decimal" use="required" />
<xs:attribute name="dunits" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="count" type="xs:unsignedInt" use="required" />
</xs:complexType>
</xs:element>
<xs:element name="Asteroids">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Asteroid" type="xs:string" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
XML transformatsioonifail
XSLT planeetide ülevaatetabeli genereerimiseks
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl"
>
<xsl:output method="html" indent="yes"/>
<xsl:template match="/">
<html>
<head>
<style type="text/css">
table, td, th { border: 1px solid gray }
td {align:center;}
</style>
<title>Dummy list of planets</title>
</head>
<body>
<h1>
<xsl:choose>
<xsl:when test="Solarsystem/Planets[@lang='est']">
<![CDATA[Planeetide ülevaade]]>
</xsl:when>
<xsl:otherwise>
<![CDATA[List of planets]]>
</xsl:otherwise>
</xsl:choose>
</h1>
<table>
<tr>
<xsl:for-each select="Solarsystem/TableHeader/Column">
<th>
<xsl:value-of select="Name[@lang='eng']"/>
<xsl:if test="@units!=''">
(<xsl:value-of select="@units"/>)
</xsl:if>
</th>
</xsl:for-each>
</tr>
<xsl:for-each select="Solarsystem/Planets/Planet">
<tr>
<td>
<xsl:value-of select="Name[@lang='eng']"/>
</td>
<td>
<xsl:value-of select="@distfromsun"/>
</td>
<td>
<xsl:value-of select="Atmosphere/@surfpress"/>
</td>
<td>
<ul>
<xsl:for-each select="Atmosphere/Component">
<li>
<xsl:value-of select="Name[@lang='eng']"/>
(
<xsl:for-each select="ChemElem">
<xsl:value-of select="."/>
<xsl:if test="@atoms > 1">
<sub>
<xsl:value-of select="@atoms"/>
</sub>
</xsl:if>
</xsl:for-each>
)
- [<xsl:value-of select="@percent"/>%]
</li>
</xsl:for-each>
</ul>
</td>
<td>
<xsl:element name="a">
<xsl:attribute name="href">
<xsl:value-of select="MoreInfo"/>
</xsl:attribute>
<xsl:value-of select="MoreInfo"/>
</xsl:element>
</td>
</tr>
</xsl:for-each>
</table>
<!--******************************************************************-->
<h1>
<xsl:choose>
<xsl:when test="Solarsystem/Planets[@lang='est']">
<![CDATA[Siseringi planeedid]]>
</xsl:when>
<xsl:otherwise>
<![CDATA[Planets of inner circle]]>
</xsl:otherwise>
</xsl:choose>
</h1>
<table>
<tr>
<xsl:for-each select="Solarsystem/TableHeader/Column">
<th>
<xsl:value-of select="Name[@lang='eng']"/>
<xsl:if test="@units!=''">
(<xsl:value-of select="@units"/>)
</xsl:if>
</th>
</xsl:for-each>
</tr>
<xsl:for-each select="Solarsystem/Planets/Planet">
<xsl:if test="@distfromsun < 1">
<tr>
<td>
<xsl:value-of select="Name[@lang='eng']"/>
</td>
<td>
<xsl:value-of select="@distfromsun"/>
</td>
<td>
<xsl:value-of select="Atmosphere/@surfpress"/>
</td>
<td>
<ul>
<xsl:for-each select="Atmosphere/Component">
<li>
<xsl:value-of select="Name[@lang='eng']"/>
(
<xsl:for-each select="ChemElem">
<xsl:value-of select="."/>
<xsl:if test="@atoms > 1">
<sub>
<xsl:value-of select="@atoms"/>
</sub>
</xsl:if>
</xsl:for-each>
)
- [<xsl:value-of select="@percent"/>%]
</li>
</xsl:for-each>
</ul>
</td>
<td>
<xsl:element name="a">
<xsl:attribute name="href">
<xsl:value-of select="MoreInfo"/>
</xsl:attribute>
<xsl:value-of select="MoreInfo"/>
</xsl:element>
</td>
</tr>
</xsl:if>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
XSLT sorteeritud tabeli genereerimiseks
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl">
<xsl:output method="html" indent="yes"/>
<xsl:template match="/">
<html>
<head>
<style type="text/css">
table, td, th { border: 1px solid gray }
td {align:center;}
</style>
<title>Sort by weight</title>
</head>
<body>
<table>
<tr>
<th>Planeedi nimi</th>
<th>Planeedi mass(Earth masses)</th>
<th>Kaugus päikesest(AU)</th>
</tr>
<xsl:for-each select="Solarsystem/Planets/Planet">
<xsl:sort select="@mass" order="descending" data-type="number"/>
<tr>
<td>
<xsl:value-of select="Name"/>
</td>
<td>
<xsl:value-of select="@mass"/>
</td>
<td>
<xsl:value-of select="@distfromsun"/>
</td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Planeetide ja nende infolinkide XML-i produtseermise XSLT
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxsl="urn:schemas-microsoft-com:xslt" exclude-result-prefixes="msxsl">
<xsl:output method="xml" indent="yes" omit-xml-declaration="yes" cdata-section-elements="Name Link"/>
<xsl:template match="/">
<Solarsystem>
<Planets>
<xsl:for-each select="Solarsystem/Planets/Planet">
<Planet>
<Name>
<xsl:value-of select="Name"/>
</Name>
<Link>
<xsl:value-of select="MoreInfo"/>
</Link>
</Planet>
</xsl:for-each>
</Planets>
</Solarsystem>
</xsl:template>
</xsl:stylesheet>
Retsensioon
Retsensioon meeskonnale HMR meeskonnalt /*Anonüümsed koodikommentaatorid*/ asub siin
Analüüs
Projekti esialgne andmebaasimudel on esitatud siin. Projekti esialgne kasutusjuhtude analüüs on esitatud siin.
Meil on firma (nimi, aadress, kontakt), või siis on elupaik (eraisikul), kus on mitu hoonet, mida jälgida. (Garaaz, kuur, elumaja, saunamaja). Igas hoones on korrused, korrustel on tsoonid, tsoonides on ruumid. Mõnikord on ühes tsoonis mitu ruumi, mõnikord ainult üks. Mõnikord on tsoonides mitu korrust korraga.Ruumides on andurid.
Anduriteks on meil liikumisandurid, akna- ja ukseandurid, temperatuuri andurid, suitsuandurid, klaasipurunemisandurid, elektripistiku andur, niiskusandur, CO2 andur, tuule suuna ja tugevuse andur, heliandur.
Anduritelt tuleb info (kas true või false või konkreetne number nagu temperatuur) mis salvestub baasi (anduri väärtus mingil ajahetkel).
Meil on kasutajad, kasutajad on jagatud rollidesse (admin, tavakasutaja, keegi kolmas), rollidel on erinevad õigused. Kui eramaja, siis adminid on ilmselt kõik pereliikmed, kolmandat kasutajat pole ja tavakasutajaks on külalised. Äripuhul on juhtkond ja spetsialistid näiteks administraatorid, kolmandad isikud siis juba erinevad ametimehed firma töötajate hulgast(koristaja, administraator, turvamees) ja tavakasutajad on kliendid ja osad töötajad kellel pole vajadust muid õigusi anda (ilmselgelt näevad nendest kasutajatest andurite väärtusi ainult need, kes pääsevad mingisse konkreetsesse ruumi, kus asub juhtpult või ekraan mis kuvab andurite väärtusi, seega päris kõik inimesed seal hoones ei kuulu tavakasutajate hulka).
Admin saab:
1.jälgida statistikat
2.näeb andurite hetke väärtusi, olekuid
3. saab panna valvesse hoonet, valvest maha
4. lülitada välja pistikuid kaugelt
5. näeb kasutajate statistikat
6. näeb ajalugu (andurite, valvessepaneku)
7. saab anda õigusi ja ära võtta
Keegi kolmas:
1. saab panna valvesse, maha võtta
2. näeb andurite väärtusi ja olekuid hetkel
3. saab välja lülitada pistikuid kaugelt
Tavakasutaja:
1. näeb andurite väärtusi ja olekuid hetkel
Veebiteenus ja klientrakendus
Anname väikese sissejuhatuse NutiHoone API-st ja klientrakendusest. Teenuse tehnoloogiaks on kasutatud RESTi ja ASP.NET Web API-t ning rakendus on tehtud ASP.NET MVC rakendusena.
Tegemist on rakendusega mis laseb inimestel mingit hoonet hallata. Samuti annab rakendus aimu hoonet iseloomustavatest parameetritest. Lühidalt on arenduse idee selles, et maja ja tema kasutaja oleks teadlik maja olukorrast. Meie arendus koosneb kahest lahendusest (solution), millest esimeseks on api ning teiseks on rakendus. Esiteks tuleb tööle panna api ning seejärel rakendus, siis peaks asi toimima.
Rakenduses on tehtud ka kasutajate haldus. Olgu märkusena ära toodud, et esimesena on mõistlik end rakenduses registreerida kasutajanimega admin@admin.ee (salasõna omal valikul). See kindlustab, et te olete sees admini õigustega kasutajana ning pääsete ligi kogu rakenduse funktsionaalsusele. Lisaks sellele saate muuta ka muude kasutajate rolle. Registreerides muu nimega kasutaja näete tavakasutaja vaadet (vahepeal tuleb admin kontoga sisse logida ja uuele kasutajale anda roll (soovitavalt user).Seejärel kuvatakse uuele kasutajale vaade, kus saab ainult tegevusi mingi ruumi vastu märkida (tegevused ja ruumid peavad eelnevalt admini poolt sisestatud olema).
Admin saab teha paljusid operatsioone. Need operatsioonid on rakenduses intuitiivselt tajutavad, klikkige vasakul menüüs olevatel linkidel ja on näha mida teha annab. Admin saab vaadata ka api kasutamise logi.
Rakenduse koodi tutvustuseks tahaks ära märkida, et seal ei kasutata eraldi andmebaasi, vaid kõik andmed asuvad api andmebaasis. Rakenduse projekti ülesehitusest võib vähesel süvenemisel taoline mulje jääda, aga selline rakenduse lahenduse struktuur tulenes sellest, et kasutasime seal Entity Frameworki kontrollerite ja vaadete loomiseks. See on tunduvalt mugavam moodus kui vaateid manuaalselt luua.
Sensorite andmete lugemiseks on loodud moodul RawDataCollectingLayer(RDCL). Arenduse ja katsetuste käigus loodi kaks veidi erinevat versiooni. Esimene neist paikeneb Api solutioni koosseisus ja kasutab loetud sensorandmete sisestamiseks baasi UOW liidest. Teine versioon on täiesti eraldiseisev solution, mis kasutab andmebaasi andmete lisamiseks Api teenust. Andmete edastus Api-le käib üle käsu POST, Api ise lisab andmed baasi. See versioon ei pea "teadama" midagi andmebaasist vaid oluline on vaid Api url. Üldiselt on tegemist vahendiga, mis kogub reaalselt andmeid internetis paiknevas andevahetuskataloogist ja lisab need Sensordata olemi tabelisse, mida api teenus saab edukalt välja kuvada. Tegemist on siis virtuaalselt loodud olukorraga, kus majas asuvate andurite näitajad ilmuvad rakenduses vaatamiseks. Selleks, et need andmed ilmuksid tuleb esimene RDCL versioon panna startup projektiks ning see siis käivitada ja lasta sel veidi aega joosta. Teise versiooni puhul piisab solutioni kompileerimisest ja käivitamiset. Vajadusel peab muutma ainult api urli. RDCL on püütud luua selliselt, et oleks võimalik kergesti luua erinevat tüüpi ühendusi. Praegu on kasutusel xml fali lugeja. Samas peaks saama tekitada lihtsalt ka TCP Klient/Server süsteemi repository.
Kahjuks tuleb lõpetuseks nentida, et käesolevaks kuupäevaks (24.05.2015) ei ole me api ega rakendus veel täielikul määral valmis. Meie meeskond plaanib projekte oluliselt kaitsmise ajaks veel täiendada. Aga usume, et hektel valmisolev annab ka aimu, et vajalikud tehnoloogiad on rakendatud ja korralik toorik on olemas.
Projektides on kasutatud reposid, liideseid, UOW-d, url-id on config faili pandud. Sisselogimine on samuti projektis üks töötav osa, parool krüpteeritud kujul. Api poolel kontrollerid nõuavad autoriseerimist. Lisaks kasutatud migratsioone. Äriloogika ja andmebaasi kiht on eraldi viidud. Lisaks api poolel kasutame vahekihti BLL, et peita rakendusele äriloogikat. Lisaks kasutame vaatemudeleid, et kuvada vaadetesse dropdown liste.
Link API ja rakenduse zip failidele: http://enos.itcollege.ee/~hluts/vr2/ RDCL/Andmete koguja http://enos.itcollege.ee/~mkabanen/vr2/
Retsensioonid veebiteenusele ja klientrakendusele
Meie grupp valis retsenseeirmiseks grupi KRTT (https://wiki.itcollege.ee/index.php/KRTT#Veebiteenus_ja_klientrakendus) töö. Retsensioon on kahes osas, kõigepealt teenuse ja seejärel rakenduse retsensioon.
Veebiteenuse retsensioon
Sissejuhatus
Grupi KRTT veebiteenus oli realiseeritud ASP.NET MVC Web API-na ning kasutatud oli REST teenust ning andmete käitlemiseks kasutati JSONi formaati. Teenuse puhul oli kasutatud töö spetsifikatsioonis ettenähtud tehnoloogiaid ning arendusmustreid. Töös oli kasutatud kenasti UOW mustrit, s.t päringud ei käinud otse andmebaasi vastu. Samuti oli andmekihis kasutatud interface, nii nagu oli projekti kirjelduses ette nähtud.
Projektis oli kasutatud code first lähenemist ning andmebaasi genereerimiseks kasutati Entity Frameworki. Et API ei annaks välja ebavajalikku infot oli projektis kenasti realiseeritud DTO (Data Transfer Object) vahekiht.
Töös oli kasutatud code first lähenemist ning andmebaasi genereerimiseks on kasutatud Entity Frameworki. Samuti on töös kasutatud nõutul määral olemeid, arvestamata seejuures sisse autentimise toimimiseks vajalike olemite arvust.
Projekti üldiste nõuete täidetus
Tulles nüüd detailide juurde siis alustuseks tuleb ära mainida, et grupi KRTT veebiteenus läks meie meeskonna liikmete arvutites ilma probleemideta tööle.
Tulles nüüd üldisemate teenuse poolele esitatud nõuete juurde, siis kõigepealt mainime ära, et teenus toimib kenasti. Projektis oli teenusele esitatud turvatuse nõue, vaatlusaluse projekti puhul on see nõue täidetud.
Samas oli teenuse puhul väike soovitus, et erinevateks toiminguteks oleks vastav haldusliides. Mingit rakendust kahjuks haldamiseks polnud. See tõstatas mõningaid küsimusi, nimelt vaikimisi oli õppejõu Andres Käveri näidiskoodis olemas MVC rakenduse kujul kasutajahalduse rakendus. Kahjuks need põhjused, miks antud rakendusest otsustati veebiteenuses loobuda ei ole meile teadlikud. Väikese märkusena võiks siiski öelda, et rakenduse olemasolu annaks API kasutamiskogemusele palju juurde.
Ilmselt siis kogu kasutajahaldus on jäetud otse andmebaasi vastu käima, see kindlasti pole hea ega turvaline praktika. Kui grupil on huvi antud projekti veel edasi arendada, siis kindlasti soovitaks luua mingi API poolse haldamise rakenduse.
Teine nõue projektis oli see, et teenus peaks pidama arvet kasutajate ning kasutusstatistika üle kasutajate lõikes. See nõue käesolevas projektis polnud täidetud, vähemalt meie grupp ei leidnud nii teenuse kui rakenduse väljundis sellele viiteid. Samuti ei leidnud me ka koodis mingeid kohti, mis viitaksid sellele, et antud nõue oleks implementeeritud.
Projekti nõudeks oli ka teenuse poole pöördumiste arvu piiramine ning piirangute haldamine. See funktsionaalsus oli samuti implementeerimata. Vähemalt meie grupp selle kohta projektis viiteid ei leidnud.
Üldine lahenduse (solution) ülesehitus
Lahendus on kenasti struktureeritud ja jaotatud eri projektide vahel. See muudab lahendusest aru saamine väga mugavamaks. Kasutatud on levinud ülesehtist, olemid on omaette projektis. Andmebaasi loogika on omaette projektis ning samuti ka API. Kuna meie grupp kasutas oma projektis sarnast loogikat, siis oli väga kerge projektis orienteeruda.
Väikese märkusena võiks lisada, et meie soovitus oleks olemite projektile (Domain) teha spetsiaalne kaust, kus on kirjas projekti olemid. Praegu olid nad otse lahenduses, hiljem kui peaks tekkima vajadus lahendust laiendada, siis erinevate olemite kirjeldamine projekti üldises juurkataloogis võib põhjustada ebamugavusi.
Koodistiil
Koodi puhul tuleb nentida, et see on kenasti vormistatud ja kergesti jälgitav. Samuti on olemite atribuutide ja meetodite nimed nimetatud nõnda, et nendest on võimalik kogu atribuudi ja meetodi sisu välja lugeda. Sellest tuleneval on koodi lugemine väga mugav ning sellest aru saamine väga intuitiivne.
Mainime ära, et käesoleva töö analüüsijatele antud lahendus meeldib. Selle asemel et kirjutada väga ebaloogiliste muutujate nimedega koodi (näiteks string x ning int y) ning seejärel kommentaarides täpsustades muutujate olemust annavad käesolevas koodis olevad muutujate ning meetodite nimetused kohe vajaliku info kätte. Meie grupp pooldab väga taolist lahendust, et kood kirjutatakse nõnda, et see kommenteerib end niiöelda ise ja ohtraid kommentaare pole tarvis.
Üldised kommentaarid
Meie meeskonnale meeldis fakt, et mudelites oli kasutatud enumeid. Kuigi mainiksime siin ära väikese kriitikana, et võibolla oleks ka nende valikuväljade puhul kasutada erinevaid objekte, et neid näiteks hiljem kasutajaliidese kaudu muuta ning hallata. Samas me ka ei kritiseeri nende kasutamist, kindlasti nad lühendasid arendamise aega.
Rääkides API projektist (WebApiApp), siis grupi kiituseks tuleb öelda, et seal on kontrollerite meetodid kenasti kommenteeritud. Samas kõrvalmärkusena võib öelda, et meetodid on nõnda nimetatud, et need annavad kohe aimu meetodi iseloomust. Samas plusspunktid nende eest.
Kokkuvõte
Kokkuvõtteks võib öelda, et API tehnilise poole pealt pole ühtegi negatiivset sõna. Kõik toimib kenasti. Kood on kirjutatud arusaadavalt, samuti on lahendus loogiliselt struktureeritud.
Miinuspoole pealt peab mainima, et kahjuks täit rakenduse funktsionaalsust (näiteks kasutusstatistika) pole hetkel veel realiseeritud.
Klientrakenduse retsensioon
Sissejuhatus
Grupi KRTT rakendus on realiseeritud Windows WPF rakendusena. Tuleb tunnistada, et meie grupile oli valik vägagi üllatav, ei osanud seda oodata.
Meie hinnangul pole antud valik selles mõttes õnnestunud, et WPF puhul tuleb väga suur osa kasutajaliidesest ise käsitsi kirjutada. Antud valikuga kaasnes ilmselt väga palju ajakulu.
Samas kui valida projektis ASP NET MVC projekt, siis seal oleks Visual Studio ise väga palju käsitööd ära teinud (CRUD vaated, Bootstrap, vormikontroll ja palju muud). Võibolla oli asi tingitud sellest, et olles äsja tulnud C# ainest oli WPF rakenduse tegemise kogemus olemas ja seega otsustas grupp KRTT panustada enda tugevatele külgedele.
Rakenduse testimine
Lühidalt öeldes tuleb nentida, et rakenduse kasutajakogemus ei olnud väga meeldiv. Kasutajaliides polnud kõige kaunim, aga see pole meie hinnangul kõige suurem miinus. Peamine probleem seisnes selles, et WPF rakendus kippus kokku jooksma. See on väga suur miinus.
Toome ühe kasutusjuhtumi analüüsi, kus rakendus lakkas töötamast. Üritades end rakenduusega registreeruda ilmneb tõsiasi, et peale vajalike andmete sisestamist mingit registreerumist ei toimu ning sisse logida pole võimalik.
Negatiivne on ka see aspekt, et peale seda kaob menüüs ära “Register” nupp, mis võimaldaks tekitada teise kasutaja, igaks juhuks testimaks, et äkki siis logimine õnnestub. Samuti puudub võimalus andmete muutmiseks. Kui on soov “Register” nupp tagasi saada siis tuleb selleks kas vajutada “Menu” või “Home” nupule. Tegemist ei ole hea kasutajakogemusega ja soovitaks seetõttu kasutajaliidese paremini läbi mõelda.
Kasutaja registreerimise vormi kohta oleks märkuseks, et salasõna väljadel ei ole hea kuvada sisestatud salasõna. Sobilik oleks kasutada standartset lahendust, kus sisestatud salasõna kuvatakse täppidena.
Viga ilmnes ka siis, et kui proovida eelnevalt Kui proovida eelnevalt sisestatud kasutajaga rakendusse siseneda, siis on tulemuseks exception, mida ei käsitleta, s.t koodis puudub „try … catch“ plokk. Viimane on aga veatundliku koodi puhul teatavasti oluline. Kasutaja seisukohast ei saa seega mitte mingisugust informatsiooni selle kohta, mis valesti läks.
Samamoodi kukub rakendus kokku kui vajutada nupule “Load cars”, sel puhul samuti ei kuvata mingisugust veateadet. Võib vaid oletada, mis on selle vea põhjuseks, kas näiteks rakendus ei saa teenusega ühendust või on mingi muu probleem. Igal juhul oleks hea sellest probleemist kasutajat informeerida.
Siinkohal on taaskord näha kui oluline on strateegiline otsus rakenduse tüübi valiku osas. MVC rakenduses oleks väga palju veahaldusest ära tehtud. See valik oleks tõenäoliselt väga palju säästnud grupi KRTT aega. Samas tuleb nentida, et ilsmelt pole grupp KRTT vigadesse väga kergekäoliselt suhtunud, vaid on proovinud neid ka lahendada. Sellele viitavad mitmed koodi sisse jäänud break pointid.
Soovitused valminud WPF rakenduse parendamiseks
Meie grupi soovitus oleks veidi mõelda üldisematele kujundusreeglitele. Hetkel on kasutajaliidese pool väga minimalistlik ja raskesti hoomatav.
Hetkel on suur valge ala “MainWindow” keskel, mis koodianalüüsist lähtudes tundub olevat auto pildi kuvamiseks, seda võib aru saada tutvudes faili Cars.xaml sisuga. Samas kui ühtegi autot valitud pole, siis jääb üldmulje vägagi tühjaks.
Meie hinnangul puuduvad WPF rakenduses kasutajaliideses kohad kõikide veebiteenuse olemite manipuleerimiseks. Näiteks meie grupile jäi selgusetuks kuidas sisestada ettevõtet (olem Firm), rendilepingut, ülevaatust või autovarustust.
Samas me ei saa väita, et seda funktsionaalust pole olemas. Põhjus seisneb selles, et me ei suutnud WPF rakenduses ennast sisse logida ja rakendust proovida. Meie arvamus põhineb puhtalt koodianalüüsil. Me ei leidnud neid teenuste, põhiolemite ega vaatemudelite alt.
Koodistiil
Koodistiili kohta pole tegelikult mitte midagi halba öelda. Kood on sarnaselt teenuse koodile kirjutatud väga puhtalt ja mõistetavalt, samuti on kood kenasti vormindatud. Samas on rakendusel väga palju bugisi, seetõttu hea koodistiil ei kaalu üles rakenduse bugisid.
Kokkuvõte
Kokkuvõtteks võib öelda, et WPF rakenduse arendamisega on mõistlik veel tegeleda. Kasutamisel ilmnes väga palju vigu ja seega me ei saanud kogu funktsionaalust testida.
Meie poolne soovitus oleks, et grupp KRTT kaaluks näiteks mõne spetsiaalse veebiliidese arendamist, miks mitte näiteks ASP NET MVC rakendus. Seal võtab raamistik rakenduse baasfunktsionaalsuse osas väga palju tööd enda kanda ning arendajatel jääb aega eriarendustega tegelemiseks.
Logi
25.02.15 - esimene projektimeeskonna käraja
06.03.15 - XML kodutöö esitamine
xml ja esialgne xslt on olemas. xsd ja üht-teist veel tuleb lähiajal.
07.03.15 - XML kodutöö esitamine
Kogu kompott peaks olema siis nüüd üles laetud
07.04.15 - Analüüsi esitamine
Analüüs üles laetud.
25.04.15 - Hackathon
Tulemus oli erinevatel põhjustel suhteliselt kesine. Positiivne oli see, et kõigil grupi liikmetel oli lõpuks olemas peaaegu ühtne versioon projektist, mis tõsi küll, mõnel ei kompileerunud.
24.05.15 - Teenus ja rakendus
Teenus ja rakendus enam-vähem(pigem vähem) valmis ning konstruktiivse kriitika jaoks avalikustatud.
30.05.15 - Retsensioonid
Retsensioonid Veebiteenusele ja klientrakendusele valmis.