Talk:Ratsa Rikkaks: Difference between revisions
No edit summary |
|||
Line 28: | Line 28: | ||
=Lõpplahenduse retsensioon= | =Lõpplahenduse retsensioon (meeskonnalt MMA) = | ||
Latest revision as of 22:49, 14 January 2013
Analüüsi retsensioon
Meeskond on valinud projektiks videolaenutuse infosüsteemi. Analüüsist saab piisava ülevaate loodava infosüsteemi oodatavast funktsionaalsusest. Tegevused kasutaja seisukohast lähtuvalt on hästi lahti kirjutatud.
Kuivõrd eesmärgiks on reliseerida infosüsteem arendamaks meeskonnatöö ja programmeerimise alaseid oskuseid, siis on niisugune valik sobiv. Reaalset ärilist rakendust võiks sarnasest valdkonnast leida näiteks tööriistalaenutuse vms infosüsteemile.
Analüüsist ei nähtu, kas rakendus realiseeritakse modulaarsena, mis võimaldaks hiljem lisada erinevaid teenuseid (mingi teise kauba laenutamine) või tegevusvaldkondi (kasutades olemasolevat kliendihalduse moodulit).
Tootekataloogi ("Filmide arvestus") osas jääb selgusetuks, kas ja kuidas õnnestub vaadata laoseisu (ehk millised filmid on laenutuseks saadaval, millised välja laenatud). Kuidas leida, kas kliendi poolt soovitud film on soovitavaks ajaperioodiks saadaval? Kuidas välditakse ühe filmi topelt laenutamist samaks ajaperioodiks? Kuidas käsitletakse mitme samasisulise toote (2tk sama filmi) olekut kataloogis, kas lisatakse eraldi kirjena? Kui ei lisata eraldi kirjena, siis ilmselt tekib probleem tuvastamisega, milline kasutaja mis ajahetkel laenutas millist konkreetset toodet (et selgitada näiteks välja, kes plaadi ära kriipis). Samas kui lisatakse eraldi kirjetena, siis kuidas realiseeritakse ülevaatlik päring saadaolevate ja välja laenutatud toodete kohta ning kas uue laenutuse loomisel peab siis otsima välja konkreetse toote või võetakse automaatselt esimene saadaolev. Samas puudub tootel väljapakutud struktuuris unikaalne identifikaator. On olemas küll automaatselt genereeritud UID, kuid selle sidumine füüsilise tootega võib osutuda probleemseks (aga samas võib ka toimida, kui näiteks rakendus prindib, või tehakse seda käsitsi, toote lisamisel sildiprinterist vastava UID'ga kleepeka, mille saab siis karbile kleepida).
Kokkuvõttes valitud töö on piisava mahuga ja selle realiseerimine antud meeskonna suurusega õppeaine raames on realistlik. Analüüs annab piisava detailsusega ülevaate loodavast rakendusest. Teema ei ole kuigi aktuaalne, puudub äriline väljund.
Koostas: Meeskond_Metronaator
Prototüübi retsensioon
Asub siin: http://akaver.com/blog/2012/12/31/c-prototuubi-analuus/
Koostas: akaver
Lõpplahenduse retsensioon (meeskonnalt MMA)
Vaadates analüüsidokumenti, on enamus realiseeritud. Esineb mõningaid vigu, kuid suurem osa on tehtud. Liiga suuri eesmärke ei võetud analüüsis. Rakendus koosneb vähestest komponentidest, mis on ka piisav erinevate programmeerimise ülesannete läbiproovimiseks.
GUI
Kasutajaliidesest on näha, et on panustatud kujundusele. On rakendatud stiile. XAML-is on kasutatud erinevaid elemente, mis aine materjalides õpetati. XAML osa juures ainus häiriv asi on see, et on kasutatud fikseeritud suurusi mõnes kohas.
Salvestamiste juures on vigaselt sisestatud väljad esile toodud punase värviga. Samas, puudub vastav tekst, mis juhendaks, mis valesti on sisestamise juures.
Mudel
xaml.cs failides on kasutatud andmebaasi konteksti, mis peaks olema vale lähenemine. Samuti toimub seal ka andmete valideerimine, salvestamine, muutmine ja kustutamine. GUI kasutamise valideerimine võib kasutajaliidese pool olemas olla kuid ei tohiks asendada mudeli poolset valideerimist. Mudeli poolel valideerimist ei ole.
Kuigi rakendus on väike, oleks võinud mudeli osa olla eraldi Class Library projekti sees. Ka samas projektis on võimalik teostada äriloogikat mudeli sees. Praegust lahendust vaadates mudel justkui puudub. Andmemudelis on ainult andmete laadimine. Ei leidnud andmemudeli CRUD-ist peale R-i midagi. Kogu äriloogika ja andmetega tegelemine on mööda esitluskihti laiali ning puudub selge koht, kus andmeid valideeritakse.
Kokkuvõte
Positiivse mulje jättis see, et lõpptootega oli kaasas kasutusjuhend. Kokkuvõtteks jäi arusaam, et on panustatud rakenduse väljanägemisele ja lisafunktsionaalsusele (baasi loomise automatiseerimine), samas kui rakenduse arhitektuuriline alustala on jäänud nõrgaks. Suurema rakenduse puhul oleks see ehk paremini välja tulnud. Aga valitud rakendus oli väike ning oli suudetud asjad toimima panna. Koodistiililt oli rakendust meeldiv lugeda ning puudustele vaatamata oli hästi arusaadav. Kõige suurem dilemma retsenseerija jaoks ongi see, et kuigi MVVM on natuke valesti kasutatud, ei teki piisavalt spageti-koodi maitset, kui arvata võiks.