Kuldneloojang

Meeskond ja projekt

• Andrus Seiman
• Marko Belzetski
• Priit Tiganik
  • Kristjan Peterson - ei osalenud arenduses

Lõpptooted:

• Veebiteenus ja klientrakendus: Link antud lehe peatükile
• XML: Link antud lehe peatükile

Retsensioonid meie projektile

Meie tööle kirjutatud retsensioonid

Veebiteenus

Retsenseerija meeskond: Kes soovib retsenseerida?

TODO

Klientrakendus

Retsenseerija meeskond: BeerPressure

retsensioon discussioni lehel

XML

Retsenseerija meeskond: Kes soovib retsenseerida?

TODO

Analüüs

Kirjeldus

Vanadekodu “Kuldne loojang” on vanadekodu nagu vanadekodud ikka. Siin kantakse igapäevast hoolt vanemate inimeste eest, kes üksi enam hakkama ei saa ja kelle eest hooldamise on lähedased inimesed usaldanud professionaalide kätte. Vananevas ühiskonnas on vajadus säärase teenuse vastu suur ja pidevalt kasvav, seetõttu on konkurents tihe. Kuna teenuse kvaliteet on vanadekodule “Kuldne loojang” südameasi, on juhtkond otsustanud investeerida teenuse kvaliteedikontrolli digitaliseerimisse. On tehtud plaan luua infosüsteem, mis aitab põetajatel pidada järge klientidega igapäevaselt sooritatavate protseduuride üle. Kuna infotehnoloogia on juhtkonnale võõras teema, siis on otsustatud alustada vaikselt ja liikuda samm haaval. Seetõttu on disainitav infosüsteem kaunis väike.

Kasutajad

• juhtkonna poolt volitatud administratiivsed kasutajad, kes jagavad kasutajate õiguseid ja kontrollivad põetajate tööd
• vanadekodu arstid, kes teostavad meditsiinilist läbivaatust ja määravad vajalikke protseduure,
• klientide lähedased või kliendid ise, kes pääsevad ligi nendega seotud kliendiga seotud informatsioonile (meditsiiniline läbivaatus, protseduurid, jne.)
• põetajad, kes saavad tutvuda tööülesannetega ning märkida neid teostatuks

Infosüsteemi funktsionaalsus

• Vanadekodu arsti vastutada on klientide tervise jälgimine.
• Vajadusel teeb arst tervisekontrolli käigus ettekirjutisi, mille järgi põetajad klientide eest hoolitsevad.
• Iga ettekirjutise kohta on teada kirjeldus, algus ja lõpu kuupäev ning sagedus, mis ütleb kui tihti protseduure ette tuleb võtta.
• Vanadekodus võib tegutseda korraga mitu arsti.
• Ühele kliendile võib ettekirjutisi teha mitu erinevat arsti.
• Kuna klientide eest hoolitsemine käib kindlate graafikute alusel, siis peab ettekirjutises märgitud protseduuri sagedus tulema lubatud sageduste sõnastikust, mis sisaldab sagedusi nagu “kolm korda päevas peale sööki”, “hommikul ja õhtuti enne sööki”, jne.
• Kui arst on ettekirjutise teinud, siis vastavalt alguse ja lõpukuupäevadele ning valitud sagedusele genereeritakse süsteemi kõik üksikud protseduurid, mis selle ettekirjutuse täitmiseks on vaja teostada.
• Protseduuride läbi viimiseks on vanadekodus põetajad. Põetajate ülesanne on klientide eest hoolitsemine ja arstide ettekirjutuste elluviimine. Kuna patsiente on palju ja ettekirjutused erinevad, siis on vaja olla hoolas. Infosüsteem on selleks, et aidata põetajatel järge pidada, mis tööd on juba tehtud või mis töid on veel vaja teha. Selleks kuvab infosüsteem kõiki ühe toa või ühe kliendi kohta tänasel päeval tehtavaid protseduure.
• Kui protseduur on täide viidud, siis saab põetaja märkida selle tehtuks ja asuda järgmiseid ülesandeid täitma.
• Lähedastel on esialgu infosüsteemis väike roll. Nemad saavad lihtsalt uurida, mis ettekirjutisi arst on nende lähedaste kohta teinud ja kas need on kõik ikka ellu viidud.
• Administraatoritel on voli luua teisi kasutajaid ja jagada neile rolle.
• Lisaks on neil võimalus kontrollida arstide ja põetajate töid ning korraldada klientide paiknemist tubades.

Andmemudel

API endpointide kirjeldus (esialgne)

Tegemist on esialgse, analüüsi käigus loodud kirjeldusega. Lõpliku dokumentatsiooni saamiseks kasuta veebiteenuse Swaggerit.

User

POST/user - Adds a new user

GET/users/{UserId} - Returns a user object for the given UserId

DELETE/users/{UserId} - Deletes the user according to user id

PATCH/users/{UserId} - Modify the user's data

GET/users - Returns all the users in the database

Guardian

POST/guardian - Adds a new patient's guardian

GET/guardians/{GuardianId} - Returns a patient's guardian by ID

DELETE/guardians/{GuardianId} - Deletes guardian according to guardian's ID

PATCH/guardians/{GuardianId} - Updates Guardian according to id

GET/guardians - Returns all Guardians

Patient

POST/patient - Adds a new patient

GET/patient/{PatientId} - Gets patient according to patient ID

DELETE/patient/{PatientId} - Deletes patient according to patient ID

PATCH/patient/{PatientId} - Modified patient's data according to patient ID

GET/patients - Returns all patients

UserType

POST/usertype - Adds a new usertype

GET/usertypes/{UserTypeId} - Returns a usertype object for the given UserTypeId

DELETE/usertypes/{UserTypeId} - Deletes the usertype according to usertype id

PATCH/usertypes/{UserTypeId} - Modify the usertype's data

GET/usertypes - Returns all the usertypes in the database

PatientRoom

POST/patientRoom - Adds a new patientRoom

GET/patientRooms/{PatientRoomId} - Returns a patientRoom object for the given PatientRoomId

DELETE/patientRooms/{PatientRoomId} - Deletes the patientRoom according to patientRoom id

PATCH/patientRooms/{PatientRoomId} - Modify the patientRoom's data

GET/patientRooms - Returns all the patientRooms in the database

Room

POST/room - Adds a new room

GET/rooms/{RoomId} - Returns a room object for the given RoomId

DELETE/rooms/{RoomId} - Deletes the room according to room id

PATCH/rooms/{RoomId} - Modify the room's data

GET/rooms - Returns all the rooms in the database

PatientsDoctor

POST/patientsDoctor - Adds a new patientsDoctor

GET/patientsDoctor/{PatientsDoctorId} - Returns a patientsDoctor object for the given PatientsDoctorId

DELETE/patientsDoctor/{PatientsDoctorId} - Deletes the patientsDoctor according to patientsDoctor id

PATCH/patientsDoctor/{PatientsDoctorId} - Modify the patientsDoctor's data

GET/patientsDoctors - Returns all the patientsDoctors in the database

MedicalReview

POST/medicalReview - Adds a new medicalReview

GET/medicalReviews/{MedicalReviewId} - Returns a medicalReview object for the given MedicalReviewId

DELETE/medicalReviews/{MedicalReviewId} - Deletes the medicalReview according to medicalReview id

PATCH/medicalReviews/{MedicalReviewId} - Modify the medicalReview's data

GET/medicalReviews - Returns all the medicalReviews in the database

GET/medicalReviews/patient/{PatientId} - Gets all medical review IDs for the given patient

FrequencyType

POST/frequencyType - Adds a new frequencyType

GET/frequencyTypes/{FrequencyTypeId} - Returns a frequencyType object for the given FrequencyTypeId

DELETE/frequencyTypes/{FrequencyTypeId} - Deletes the frequencyType according to frequencyType id

PATCH/frequencyTypes/{FrequencyTypeId} - Modify the frequencyType's data

GET/frequencyTypes - Returns all the frequencyTypes in the database

Kasutajalood ehk üldisem kliendi funktsionaalsuse kirjeldus

Kasutajalood-funktsionaalsus erinevatele rollidele. Kasutatud ERD tabelite nimetusi. Nice-to-have funktsionaalsus on märgitud tärniga (*).

Administraator

Soovin

• Lisada/muuta/kustutada tubasid
• Lisada/muuta/kustutada kasutajaid: hooldaja, arst, patsient, kliendi lähedane
• Lisada/muuta/kustutada Patient seost Room-is
• Lisada/muuta/kustutada FrequencyTypesid
• Lisada/muuta/kustutada kõiki muid mõeldavaid asju kõikide tabelitega *

Arst

Soovin

• Patsiendi külge lisada uut MedicalCase-t
• MedicalCase külge lisada Prescription ja määrata selle sagedus
• Saada ülevaadet enda MedicalCase-dest
• Saada ülevaadet enda patsientidest
• Enda ühe Patienti raames ülevaadet
  • tema MedicalCase-dest
  • Prescription-itest
  • Procedure-dest

Patsient või kliendi lähedane

Soovin

• Saada ülevaadet enda kõikidest MedicalCase-dest
• Saada ülevaadet enda Prescription-itest
• Saada ülevaadet enda Procedure-dest
• Saada teada, mis toas ma asun

Hooldaja

Soovin

• Teada, millised Procedure pean järgmisena tegema
• Märkida üks (või mitu korraga*) Procedure tehtuks
• Ülevaadet, milliseid procedure-sid ma pean tegema mingis kuupäevavahemikus*
• Ülevaadet, milliseid procedure-sid ma olen mingis kuupäevavahemikus teinud*

XML ülesande kirjeldus

Kuna antud ülesandega tuli kokku päris palju faile, ei ole hakatud nende sisu siia kopeerima, vaid kõik failid leiab üles sellelt aadressilt: https://drive.google.com/drive/folders/1HzdoZaEJ-i475aFXH-OfYER7Try0fNne

Failide nimekiri:

• KuldneLoojang.wsdl - infoks WCF SOAP teenuse kirjeldus, mille abil näidis-XML ja xsd said loodud
• KuldneLoojang.xsd - XSD fail XML-i sisu kirjeldamiseks
• KuldneLoojangExample_forXML.xml - XML näidis, millesse on lisatud HTML-iks transformeerimise XSLT faili link
• KuldneLoojangExample_forHTML.xml - täpselt sama XML näidis nagu eelmine, aga sellesse on lisatud HTML-iks transformeerimise XSLT faili link
• KuldneLoojang_toHTML.xslt - meie XMList HTMLi transformatisioonid
• KuldneLoojang_toXML.xslt - meie XMList väikese uue XMLi transformatisoonid

XMLi näide pärineb enam-vähem meie veebirakenduse andmestruktuurist, kuigi lihtsuse nimel on seda veidi muudetud, nimelt on guid lühendatud ning käsitsi lisatud mõned attribuudid. XML-ist leiab väikese infohulgaga patsiendid, kellel on omakorda küljes nimekiri temaga seotud haigusjutudest (Medicalcase) ning viimaste küljes võib olla veel hulk raviprotseduure (Prescription). XMLi näidetes on alles jäetud SOAP päised ja nimeruumid. Kuigi need lisavad andmete töötlemisel keerukust, on nimeruumidega tegelemine eluliselt vajalik oskus ja seetõttu ei hakanud neid ka eemaldama ja XMLi lihtsamaks muutma. Kolmele XMLi tasemele on lisatud andmete lisakirjeldusena atribuute.

Järgnevalt veidi lähemalt transformatsioonidest.

KuldneLoojang_toHTML.xslt

Õppejõu poolt antud ülesanne nõudis paljude erinevate XSLT võimaluste kasutamist. Otsustasime erinevaid transformatisoone kasutada erinevate HTML tabelite loomiseks.

Esimeses tabelis on ära toodud Kuldne Loojang hooldekodu kõikide patsientide nimekiri kasutades xsL:for-each meetodit. Lisaks antakse igale reale xsl:choose abil klassi nimetus vastavalt patsiendi soo atribuudile. Nõnda on lõpptulemuses mehed värvitud siniseks ja naised roosaks.

Teises tabelis antakse ülevaade patsientide ravist ning välja on kogutud kõik raviprotseduurid. Nende külge on omakorda otsitud XPath ancestor meetodiga nende protseduuride haiguslood ja patsiendid. Lisaks on andmed patsiendi perekonnanime järgi sorteeritud.

Kolmandas janeljandas tabelis on välja otsitud ilma ravita patsiendid. Neid saab eristada kahte viisi kasutades. Esiteks on haiguslugudel XMLis küljes info, kas neil on küljes raviprotseduure või mitte. Seda lahendust kasutab kolmas tabel. Neljandas tabelis loetakse XSLT abil kokku, mitu raviprotseduuri ravijuhtumil küljes on ning kui neid ei ole, siis kuvatakse patsiendi andmed.

Lõplik transformatsioon näeb meie andmetega välja alljärgnev:

KuldneLoojang_toXML.xslt

Kuna HTMLi transformeerimisel on kasutatud juba teatud hulk nõutust, siis XMLi transformatsioon sai üpris lihtne. Selle tag-ide nimetused on muudetud eestikeelseteks ning kokku on kogutud kõik raviprotseduurid. Lõpptulemus näeb välja alljärgnev:

<?xml version="1.0" encoding="UTF-8"?>
<ettekirjutused>
	<ettekirjutus id="9223d9c2">
		<kirjeldus>võta Sudafedi</kirjeldus>
		<algus>2018-01-01</algus>
		<lopp>2018-01-14</lopp>
	</ettekirjutus>
	<ettekirjutus id="35c813bd">
		<kirjeldus>loputa nina</kirjeldus>
		<algus>2018-02-01</algus>
		<lopp>2018-02-14</lopp>
	</ettekirjutus>
	<ettekirjutus id="d10d3379">
		<kirjeldus>võta rögalahtistit</kirjeldus>
		<algus>2018-03-01</algus>
		<lopp>2018-08-14</lopp>
	</ettekirjutus>
	<ettekirjutus id="220d3379">
		<kirjeldus>võta valuvaigistit</kirjeldus>
		<algus>2017-01-01</algus>
		<lopp>2017-01-14</lopp>
	</ettekirjutus>
</ettekirjutused>

Lõpptoode

Kood / Versioonihaldus

Lõpptoode

https://www.dropbox.com/s/4h9bvq4k6388fmo/loojang.zip?dl=0 (seisuga 02.06.2018, bugide parandusi lisatud 04.06.2018)

Versiooni haldus

Veebirakendus https://bitbucket.org/itcollegeprojects/loojang-app/

Klientrakendus https://bitbucket.org/itcollegeprojects/loojang-client/

Käivitamine (retsensentidele)

Ettevalmistus.

Projekti paigaldamiseks on kaks varianti: 1) kloonida mõlemad repositooriumid või 2) alla laadida .zip fail ning lahti pakkida see sobivasse kohta. Viimasel juhul paigaldatakse nii veebi- kui ka klientrakendus korraga.

Veebirakendus.

Avada Visual Studios LoojangApp solution ning käivitada projekt Web App läbi. Kuna kõik vaated on projektist eemaldatud, siis avaneb tühi aken. Sealt tuleb välja lugeda veebiaadress, mille poole klientrakendus pöörduma peab. Meie puhul oli selleks: https://localhost:44382. On võimalik, et igas süsteemis on see erinev. Sellisel juhul tuleb vastav aadress meelde jätta ning kopeerida see klientrakenduse sätetesse. Vastasel juhul ei oska klient veebirakenduse poole pöörduda.

Klientrakendus.

Peale kloonimist käivitada käsurealt klientrakenduse kaustas käsud projekti ehitamiseks ning käsud käivitamiseks:

npm install (vajalik vaid esimesel korral, sest paigaldab vajalikud paketid)

npm run start-en või npm run start-ee (vastavalt inglise või eesti keelse rakenduse käivitamiseks)

Kui backendi aadress erines meie poolt kasutatavast (https://localhost:44382), siis tuleb otsida klientrakenduse kaustas src/enivornemnts/environments.ts ja src/enivornemnts/environments.prod.ts failis ära muutuja apiUrl väärtused. Selle aadressi pihta teeb klient päringud ja see peab ühtima veebirakenduse aadressiga.

Rakenduses on neli erinevat kasutaja tüüp: admin, doctor (arst), caretaker (hooldaja) ja guardian (lähedane). Nendele on loodud vaikimisi kasutajad vastavalt: admin@eesti.ee, doctor@eesti.ee, caretaker@eesti.ee. guardian@eesti.ee. Kõikide parool on aaaaaa. Kasutajaid võib vabalt juurde teha, kuid uued loodud kasutaja on õigusteta ning neile peab õigused andma mõni olemasoleva admin kasutaja.

Uues andmebaasis esimest korda käivitamisel täidetakse baasis ainult FrequencyTypes tabel, ülejäänud info patsientide, tubade jne kohta tuleb retsensendil ise klientrakendusse sisestada ja asuda seoseid looma. Kuna teiste rollide õigused on muudatuste tegemiseks andmebaasis on piiratud, tuleks alustada andmete sisestamist rollis "admin".

Tegevuste logi

Analüüs ja dokumentatsioon

• 2018-03-06 Meeskonna loomine, teema fikseerimine
• 2018-03-14 Esialgne analüüs ja andmemudel
• 2018-03-16 API kirjeldus Swaggeris
• 2018-03-23 Wiki lehe loomine
• 2018-05-31 XMLi osa täiendamine wikilehel
• 2018-06-01 Veebiteenuse ja klientrakenduse kokkuvõtte lisamine

Veebirakendus

• 2018-03-20 Repositooriumi loomine TFS-is. Mudelite ja DAL-i seadistamine.
• 2018-03-23 Andmebaasi kiht EF baasil püsti.
• 2018-03-30 Analüüsi lõplik vormistamine wikis. Äriloogika arendamise algus.
• 2018-04-10 Kasutajalugude lisamine wikisse. Swaggeri integreerimine koodi.
• 2018-04-13 Identity lisatud veebirakendusele.
• 2018-04-15 Veebirakenduse äriloogika selgroog püsti (Factoryd, DTO-d ja Serviced enamikele olemitele). Algas suurem kontrollerite tegemine.
• 2018-04-28 Enamus CRUD operatsioone ja vastavaid kontrolleried töökorras. Edaspidi arendati palju asju paralleelis kliendiga ning täiendati vastavalt veebiteenuse äriloogikat või kontrollereid.
• 2018-05-06 Logimise lisamine veebirakendusele.
• 2018-05-16 Enamus kontrolleritesse sisseviidud turvakontrollid vastavalt kasutaja rollile või id-le.
• 2018-05-20 Täiendavad turvalisuse nõuded sisse viidud
• 2018-05-30 Koodi puhastamine. Kasutamata kontrollerite ja vaadete eemaldamine.

Klientrakendus

• 2018-04-09 Pandi algus klientrakenduse arendamisele.
• 2018-04-12 Esimene vaade püsti.
• 2018-04-12 i18 mustriga kakskeelsuse toe lisamine.
• 2018-04-17 Rollide põhine roiting.
• 2018-04-22 Baas pipe-d olemite sortimiseks või filtreerimiseks.
• 2018-05-01 JWT tokeniga sisse logimine.
• 2018-05-09 Vaadete lisamine (toad, arstlikud läbivaatused).
• 2018-05-15 Navigation-bari lisamine.
• 2018-05-21 Protseduuride ja nende sageduse lisamine.
• 2018-05-25 Kasutajahaldus.
• 2018-05-29 Tokeni talletamine.

Projektliikmete panus

• 1/3 Andrus Seiman (valdav osa klientrakenduse koodist, andmemudeli ja EF andmebaasikihi loomine, analüüs, wiki)
• 1/3 Marko Belzetski (suurem osa äriloogikast ja kontrolleritest, turvalisuse nõuded ja nende täitmise kontrollimine, analüüs)
• 1/3 Priit Tiganik (suur osa äriloogikast ja kontrolleritest, protseduuride ja ettekirjutuste vaated klientrakenduses, analüüs, XML-osa, wiki)
• Kristjan Peterson loobus üsna algul isiklikel põhjustel. Rakenduste loomises ei osalenud, küll aga panustas analüüsi ja wiki-lehe loomisse.

Meie tehtud retsensioonid

Veebiteenusele

Retsensioon meeskond Curry veebiteenusele link

Meeskond Curry on loonud krüptovaluuta tehingute vahendamiseks mõeldud veebiteenuse. Veebiteenuse kaudu saab luua omale kasutaja ja hiljem loodud kasutaja andmeid kasutades panna üles krüptovaluutade vahetustehinguid. Kasutaja saab valida, kas müüa või osta mingit valuutat. Tehingu toimimiseks on vajalik vastaspool ehk keegi teine, kes soovib teha vastupidist tehingut. Kui vastaspoolt ei leita, siis jääb tehing ootele, kuni vastaspool tekib. Äriloogiliselt oli valitud teema ilmselt üpris keerukas.

Projekt on arhitektuuriliselt üles ehitatud vastavalt õppeaine käigus õpetatud nõuannetele ehk projektil on nö. kihiline arkitektuur, mis võimaldab asju kihi kaupa vajadusel asendada. See on võimalik, sest kihtide vahelised ühendused on kirjutatud kasutades liideseid. Selgelt on eristatavad andmete kiht, äriloogika kiht ning veebiteenuse kiht. Need kihid on jagatud veel omakorda alamkihtideks.

Veebiteenuse domeeni mudel koosneb 11 olemist, millest üks on jäetud kasutaja andmete jaoks. Olemid kirjeldavad valuutasid ja nendega kaubeldavaid valuuta-paare, tehinguid koos tehingu staatuse ja tüüpidega ning konto seisu, jne. Andmemudel on põhjalik ning koostatud tulevikkuvaatavalt. Sellise andmemudeli pealt saab luua funktsionaalsust, mida sellises keskkonnas kindlasti kliendid tahaksid näha, kuid hetkel pole veel implementeeritud. Näiteks oma konto seisu ajalise muutuse jälgimine, valuutakursside liikumine ajas, erinevat tüüpi tehingud, jne.

Andmemudeli (Domain) juures on kasutatud annotatsioone, et määrata ära väljade pikkusi, serialiseerimist, jne. Kuid andmete seisukohalt peaks määrama rangemalt, millised väljad on kohustuslikud. Hetkel lubataks andmebaasi panna ka sellised tehinguid, kus näiteks puuduvad tehingu osapooled või valuutad, jne. Õnneks on vastav kontroll enamasti äriloogika poolel. Proovisime teha tehinguid, kus osa infot oleks puudu, aga need ei läinud läbi. Samas kui üritasime lisada uusi valuuta paare, kus puudusid teatud väljad, siis õnnestus saada andmebaasi viga ning teenus kokku jooksutada.

Annotatsioonid (näiteks välja pikkused) on puudu DTOde küljest, mistõttu kontrollerite ModelState.IsValid kontroll ei pruugi anda oodatud tulemust ja teenuste kihile võidakse edasi saata andmeid, mis andmemudelile tegelikult ei vasta. Selle probleemi testimiseks proovisime lisada kasutaja, kelle nimi oli pikem kui domeenimudelis kirjeldatud 64 tähemärki ning teenus jooksis oodatult kokku.

Andmete kättesaamise kihid on läbimõeldud. Tore on näha, et lahendusi on erinevaid ning kõik ei kasuta UnitOfWork mustrit. See on antud mahuga projekti juures mõistlik lähenemine. RepositoryProvider/RepositoryFactory mustriga oleks saanud mõned repositooriumid jätta kirjutamata, sest nendes polnud erimeetodeid, kuid see õnneks oli väike lisatöö.

Kontrollerid on väga kenasti annoteeritud. Lisaks autoriseerimise annotatsioonidele on kasutusel annotatsioonid, mis annavad teada tagastatavad objekti kuju ning võimalikud http staatuskoodid. Nende pealt on loodud swaggeriga API dokumentatsioon, millega on klientrakenduse kaudu võimalik ka tutvuda. Kontrolleritest kasutavad async meetodeid ainult kasutaja kontroller. Kui teenuse kasutusmahud kasvavad, tasuks ka teised kontrollerid kasutaja kontrolleri näitel ümber ehitada.

Koodi paigaldusjuhised on lakoonilised, piirdudes ühe lausega: “Proovimaks administraator õigustes kasutaja funktsionaalsust, logi sisse kasutajanimega 'adminuser' ning parooliga 'Kala1.maja'”. Sõnagi pole juttu sellest, et uues masinas paigaldamiseks peab looma kõigepealt andmebaasi, jne. Seda asja annaks parandada. Samas on see viga, mis on ühine paljude teiste projektidega. Õnneks sai peale järelepärimist projekti autorilt juhiseid juurde. Retsenseerijale oleks olnud abiks ka lahenduse kirjeldus. Näiteks, et mis eesmärk mingil olemil on, kuidas ja milliseid teenuseid kasutatakse kasutajalugude lahendamiseks jne. Tööde nimekirjas Wiki lehle on ära toodud vaid erinevate etappide alustamise aeg ning sellest ei ole võimalik välja lugeda, kuidas arendusprotsess toimus ning kes ja kui palju panustas. Veebiteenusel paistab puuduvat logide või mingisuguse muu lahendusena kasutusstatistika kogumise võimalus.

Kokkuvõtteks võib öelda, et meeskond Curry on demonstreerinud edukalt, et nad on omandanud õppeaine õpiväljundid. Loodud projekt peegeldab seda, mida poolaasta jooksul on õpitud ning endale ülesandeks võetud keerukas äriloogika on edukalt ja jätkusuutlikult realiseeritud.

Klientrakendusele

Retsensioon meeskond Curry klientrakendusele link

Meeskond Curry on loonud klientrakendusena kliendi oma poolt loodud veebiteenusele. Kaks asja koos moodustavad platvormi, mida saab kasutada krüptorahadega kauplemiseks. Platvorm toimib põhimõttele, et igaüks saab tulla ja luua omale konto, kus saab ülevaate oma krüptorahakoti seisust. Testimiseks täidetakse kasutaja rahakott juhuslike arvude generaatori abil erinevate krüptovaluutadega. Kasutajal on võimalik panna üles ordereid meelepäraste valuutapaaride vahel täpsustades soovitud hinna, koguse ja tehingu tüübi (ost või müük). Orderid jäävad seni üles, kuni leidub vastaspool, kes soovib viia läbi vastupidise tehingu. Seepärast on soovitatav rakenduse testimiseks teha kaks kontot, kelle vahel siis tehinguid ellu viia.

Klientrakendus on teostatud Angulari raamistikus. Klientrakendus on kirjutatud veebiteenuse solutioni sisse, mistõttu käib tema käivitamine mugavalt üheskoos veebiteenusega. Klientrakenduse projekti ülesehitus on selge ja arusaadav. Kood on suudetud hoida puhas. Mõned komponendid on siiski päris suured ja võiks ollaväiksemateks osadeks jaotatud. Esineb mõningat koodi kopeerimist, mida oleks võimalik vähendada kirjutades asju komponentidesse. Näiteks tehingute teostamisel on ostu- ja müügitehingu vormid ühesugused, mida oleks lihtsalt saanud hoida ühes komponendis. Rakenduse kasutamise, ega paigaldamise kohta pole mitte mingisugust informatsiooni. Õnneks on talupoja mõistusega rakenduse käivitamine siiski võimalik. Tuli avada vastav solution, luua lokaalne andmebaas ning seejärel käivitada solutionis vastav projekt (WebApp), mis pani korraga käima nii veebiteenuse kui ka klientrakenduse. Järgnevalt mõningaid tähelepanekuid rakenduse kasutamise kohta:

• Kasutaja loomisel valideeritakse kenasti kasutajaandmeid. Pole võimalik sisestada liiga lühikest nime või liiga lihtsat parooli. Kasutaja loomisel antakse kenasti tagasisidet, kui üritatakse luua kasutajat, kelle kasutajanimi või email on juba kasutusel.
• Kasutajal on võimalik muuta kasutajaandmeid - eesnimi, perekonna nimi ning email. Paraku pole võimalik muuta ei parooli ega kasutajanime.
• Klientrakendus näeb selge ja puhas välja. See on saavutatud Bootstrap CSS raamistiku kasutamisega.
• Äriloogika on krüptovaluutade-võõrale kasutajale pisut segane. Kliendi vaatest on näha, et kauplemine on võimalik vaid kahe valuuta suhtes (Bitcoin ja Ethereum). See tähendab, et üks kahest peab olema alati valitud. Seejärel saab kasutaja valida, mis valuuta on tehingu vastaspooleks. See tähendab, et kui näiteks soovitakse vahetada Monero valuuta Agrello vastu, siis tuleb kõige pealt Monero vahetada Ethereumi vastu, mis seejärel vahetatakse Bitcoini vastu, mille eest lõpuks saab osta Agrello valuutat.
• Huvitaval kombel saab kasutaja olla iseenda tehingu vastaspooleks. See tähendab, et kui kasutaja on pannud üles orderi ostmiseks ja seejärel ka müümiseks, siis ka selline tehing läbi viiakse.
• Klientrakenduses on puudu loogilisi funktsionaalsuseid, mis võiks olla seda sorti platvormil realiseeritud. Näiteks kasutajana sooviksin näha enda poolt läbiviidud tehingute ajalugu või sooviksin tühistada enda poolt üles pandud orderieid, jne.
• Kliendipoolelt paistab välja üks äriloogika viga. Näiteks kasutaja krüptovaluutade bilanss ei muutu nii nagu eeldaks. Viies läbi müügi tehingu, kus hind on 10 ja kogus 5, siis müüdava valuuta kogus väheneb vaid 5 võrra, mitte 50 võrra nagu oleks eeldanud. Seda kas selle vea põhjustab kliendi või rakenduse pool peaks välja selgitama koodi põhjalikum analüüs.
• Selliseid vigu, mis suudaksid klientrakenduse kokkujooksutada või panna ta andma veateatei, ei suudetud leida.

Kokkuvõtvalt võib öelda, et meeskond Curry on näidanud, et oskavad klientrakendust luua ning saavad aru kuidas klientrakendus peab suhtlema veebiteenusega. Puudused, mis saab välja tuua pole tehnilist laadi vaid pigem seotud sellega, et klientrakenduse poolele on realiseeritud skoop väiksem, kui võiks antud rakendusest eeldada.

XML-ile

Retsensioon meeskond Curry XML-ile

XML on süntaksilt korrektne vastavalt validaatorile https://www.w3schools.com/xml/xml_validator.asp

XML ja XSD on kooskõlas vastavalt https://www.freeformatter.com/xml-validator-xsd.html

XML-i ülesehitus on selline, millist retsenseerija varem näinud ei ole. Kui tavaliselt on erinevad elemendid paigutatud loogiliselt üksteise sisse, siis antud näites on alguses ära toodud linnad ning neile antud id. Järgnevalt on eraldi ära kirjeldatud riigid, mille sees on element, mis id abil viitab eelnevalt kirjeldatud linnale. Objektidevahelised seosed on küll olemas, kuid fail on tänu sellele mahukam, see on raskemini loetav ning ilmselt on raskendatud XMLi töötlemine XPATHi abil, millest enamus eeldab parent-child tüüpi seoseid, mitte relatsioonilisust. XMLi elementidel on piisavalt attribuute ning objektid on piisava sügavusega.

Esimesel XSLT versioonil oli paar tähemärki algusest puudu, kuid need parandati kiirelt ning seejärel sai XSLT abil väikese HTML tabeli kui uue XMLi. Tabeli loomisel on kasutatud peamiselt for-each tsükleid ning leidub üks tingimuste kontroll. Kasutatud on xsl:key attribuuti.

XMLiks transformeeriv XSLT on oma ülesehituselt veidi lihtsam, kuid seal on ühe huvitava lisana kokku loetud ja kuvatud lapselementide arv. Ühe võimaliku murekohana pole tulemusena saadavas XMLis välja toodavad riigid grupeeritud eraldi tagi <Country> vahele. Seetõttu, kui meid huvitaksid näiteks Leedu linnad, peaksime me praegusest XMList otsima Leedu nimele järgnevaid linnasid <Towns> , mis on samas enne järgmist <name> tagi. Lihtsam oleks võtta ainult järgmised <Towns> elemendid, kuid mõnel riigil võivad need ka puudu olla ja sellisel juhul võime saada tulemuseks teise riigi linnad.