WatchWinders

Meeskond

Toomas Juhkov, toomas.juhkov@gmail.com
Tiit Kuuskmäe, tiit.kuuskmae@gmail.com
Kunnar Kukk, Kunnar.kukk@gmail.com

Tegevuste logi

08.02.2018 - meeskonna loomine, kokkuleppe sõlmimine teema osas
10.02.2018 - õppejõu teavitamine koos esmase andmemudeliga
15.02.2018 - lõpliku andmemudeli valmimine(versioon 5)
18.02.2018 - õppejõu kinnitus, et teema ja meeskond kvalifiseeruvad
22.02.2018 - viki lehe loomine ja analüüsi koostamise alustamine
26.02.2018 - tiimi lisandus Kunnar Kukk
01.03.2018 - tiimi sprint koosolek(seoses täiendava tiimiliikme lisandumisega täpsustasime skoopi)
03.03.2018 - alustasime koodi kirjutamisega (tabelid klassideks ja annotatsioonid peale)
06.03.2018 - täiendasime andmemudelit olemiga "UserTypeState" (et saaks muuta kasutajatüüpi)
08.03.2018 - tiimi sprint koosolek
18.03.2018 - lisasime olemid "Address", "AddressU", "AddressM", "OfferOfUser", "MediaInOffer"
22.03.2018 - tiimi sprint koosolek, mis oli pühendatud andmemudeli täiendamisele
23.03.2018 - pikem tiimi hackathon andmemudeli teemal
29.03.2018 - täiendatud wiki lehte täielikult ringitöötatud andmemudeliga

Kasutatavad metoodikad

WatchWinders projektis plaanime kasutada peamiselt kaht metoodikat:

1. läbiv retsenseerimine (üks paariline teeb midagi valmis ja teine teeb sellele ülevaatuse; üksus lisatakse kui ülevaatus on lõplikult läbitud ning osapoolte vahel on saabunud konsensus)
2. paaris programmeerimine (istume ühe masina taha maha ja kirjutame kolmekesi)

Tulenevalt kaugõppe formaadist saab ülekaalus olema esimene variant. Teist metoodikat kasutame nende osade kirjutamiseks, mille puhul võib arvata, et nende lahendamine on keeruline või et lahenduskäike võib olla väga erinevaid. Püüame jooksvalt siinses vikis kajastada ka seda, millise metoodika järgi üks või teine osa valmis.

Projekti osad

Alljärgnevalt anname ülevaate projekti osadest:

(1) andmemudel
(2) veebiteenuse analüüs
(3) Minimum Viable Product definitsioon
(4) Inkrement #1
(5) Inkrement #2
(6) Inkrement #3

Projekti osad on meie viki lehel kirjeldatud valmimise järjekorras.

Andmemudel

Andmemudeli koostamisel lähtusime õppejõu ette antud kriteeriumist, mille järgi andmemudelis on vähemalt 6 põhiolemit (tähistatud tumesinise ja lillaga - meie mudelis 11 tk), mille hulgas ei sisaldu kasutajate tabelit (Person).

Põhiolemid:

• Watch - kell
  
• Person - kasutaja/kollektsionäär või firma esindaja
  
• Box - kellakarp
  
• Organization - tootjad, edasimüüjad, hooldus
  
• Settings - kellakarbi seade
  
• Offer - pakkumine kollektsionäärile
  
• Media - meediafailid kellade ja karpide kohta
  
• Address - kasutaja/organisatsiooni aadress
  
• ElectronicContact - elektrooniliste kontaktide loend
  
• Log - logi
  
• Access - paroolid ja kasutajanimed
  
• Error - vead
  

Type abiolemid:

• WatchType - kellatüübid
  
• PersonType - isikutüübid: admin, kasutaja
  
• OrganizationType - organisatsioonitüübid: tootja, hooldaja, edasimüüja jt
  
• ActionType - logi tüübid
  
• ContactType - elektroonilise kontakti tüüp: skype, email, telefon jt
  

Olekud:

• PersonTypeState - isiku rolli kehtivus ajahetkel (isiku ja tüübi vaheline seos)
  
• OrganizationTypeState - organisatsiooni olek(ud) ajahetkel
  

Kuuluvus:

• PersonWatch - isikute ja kellade vahelised seosed
  
• PersonBox - isiku ja karbi vaheline seos
  
• PersonAccess - isiku ja autentimisandmete vaheline seos
  
• WatchInBox - kella ja karbi vaheline seos
  
• ErrorInWatch - vea ja kella vaheline seos
  
• SettingsInBox - seade ja karbi vaheline seos
  
• WatchInOrganization - kella ja tootja vaheline seos
  
• PersonInOrganization - isiku ja ettevõtte/organisatsiooni vaheline seos
  
• SettingsOfWatchType - seade ja kellatüübi vaheline seos
  

Abstraktsioonid:

• Locator - abstraktsioon erinevate kontaktitüüpide jaoks
  
• Party - abstraktsioon erinevate inimeste, organisatsioonide jt jaoks
  

Kommunikatsioon:

• OfferToPerson - isikule suunatud pakkumised
  
• OfferFromPerson - isikult lähtuv pakkumine
  

Andmemudel valmis (1) metoodika abil, vt lähemalt projekti metoodikate sektsioonist.

Veebiteenuse analüüs

Alljärgnevalt esitame kellakarpide infosüsteemi analüüsi järgmistes osades:

(1) toote/teenuse kirjeldus
(2) probleemi kirjeldus
(3) lahendus
(4) süsteemi kasutajad
(5) loodava API võimalused
(6) funktsionaalsed nõuded
(7) mittefunktsionaalsed nõuded

Toote/teenuse kirjeldus

Teenuse eesmärgiks on lahendada probleem, kuidas jälgida kellakarpide kaudu mehhaaniliste käekellade seisundit ning keerata neid automaatselt üles distantsilt, näiteks juhul, kui kellade kollektsionäär ei asu füüsiliselt igapäevaselt oma kellade juures. Teenus võimaldab ka tootjal uuendada kontaktandmeid, saata personaalseid teateid. Administraatorile annab ülevaate platvormis toimuvast.

Probleemi kirjeldus

Mehhaaniliste käekellade kollektsionääride huvi kellakarpide vastu on mitmetahuline. Kollektsionääre huvitab arvepidamine – mitu kella, missuguste omaduste ja eripäradega neil kollektsioonis on. Teisalt soov eksponeerida oma kogusid kolleegidele ja sõpradele. Kellakarpidega täidetud sein või riiulid loovad selleks suurepärase võimaluse. Kolmandaks praktiline vajadus tagada kellavedrude õige vinnastatuse aste. Kaasaja mehhaanilised kellamehhanismid (automatic) võimaldavad kellakorpuse füüsilisel liigutamisel kellavedru automaatselt vinnastada.

Näiteks piisab kella kinnitamisest käele, et see hakkaks end käe liigutamisel üles keerama. Kuidas keerata aga üles seisvat kella, mis seisab paigal kellakarbis? Selleks on tänapäeva kellakarpides elektrimootor, mis tagab kella liigutamise vastavalt kellatüübile ettenähtud ööpäevase graafiku alusel. Kollektsionääride üheks probleemiks on see, kuidas juhtida sellist karpi ja omada jooksvat ülevaadet kõikidest oma karpidest, nende tehnilisest seadistusest ja kollektsiooni kuuluvatest kelladest olles tööreisil välisriigis?

Lahendus

Probleemi lahendamiseks ehitame REST + ASP.NET Core + WebAPI koos kliendiga, mis võimaldab kellakollektsionääridel hallata kellasid karpides, administraatoritel saada ülevaate süsteemist ning tootjatele lisada infot kollektsionääridele. Käesoleva projekti käigus ei tegeleta kahe IoT lahenduse kui terviku seisukohast olulise nüansiga: (i) karbi püsivara (firmware) loomisega, (ii) klientrakenduse frontend lõpliku häälestamisega (ilus .css ja pildid).

Süsteemi kasutajad

Kollektsionäär - haldab ja muudab infot oma kellade ning oma kellakarpide kohta.
Administraator - haldab süsteemi infot, vajadusel eemaldab probleeme.
Tootja - saab saata süsteemi kollektsionääridele mõeldud infot.
Hooldaja - saab infot hooldamist vajavate kellade ja -karpide kohta.

Loodava API võimalused

Alljärgnevalt vaatame loodava API võimalusi kasutajagruppide kaupa:

Kasutajale/kellakollektsionäärile

• Saada ülevaade kelladest ja kellakarpidest (lisada, muuta, vaadata).
• Muuta karbis oleva kella kohta käivat informatsiooni (kella nimi, tootja, tootmise aeg, viitenumber, mehhanism, jõureservi jääk (valikuline), foto kellast, kellarihma liik, muu).
• Karpe juhtida (keerata automaatselt üles). Näha ja muuta kella üleskeerava mehhanismi liikumise kiirust ja muid detaile (nt liikumise suund).
• Näha karbi seisundit, kas karp on hetkel wifiga ühendatud või mitte.
• Näha karbilt saabunud veateateid.
• Sisestada infot kella seisundist.
• Suhelda hooldajate ja tootjatega

Tootjale

• Uuendada kontaktandmeid.
• Saata personaalseid teateid kellakollektsionääridele.

Administraatorile

• Näha võrku ühendatud karpide arvu.
• Näha karpidesse paigaldatud kellade nimistut (ilma muude kasutajaandmeteta).
• Näha kellade üleskeeramise mehhanismide arvnäitajaid (madalaim kiirus, keskmine kiirus, tippkiirus; samuti liikumise suundade arvnäitajaid).
• IP-aadresside järgi ülevaadet, millistes riikides karpe kasutatakse (üldised arvandmed).
• Veateatega karpide arv süsteemis (üldised arvandmed).

Funktsionaalsed nõuded

• Kõik tegevused peavad olema autoriseeritud.
• REST + ASP.NET Core + WebAPI tagastab infot valideeritud JSON formaadis.
• API veatöötlus on tehtud, kasutades standardseid veakoode.
• API-le on tehtud 'health check'.
• Kõik kasutajad peavad saama end autoriseerida.
• Kasutaja, tootja ja administraatori tegevused logitakse.
• Logi ei ole muudetav, vaid on kättesaadav.
• Kasutaja ega tootja ei näe teiste kasutajate ega tootjate infot.
• API klient on kohanduv mobiilile, tahvlile ja desktoparvutile.
• Sisendandmed on valideeritud.

Mittefunktsionaalsed nõuded

• API-le on lisatud Swagger fail.
• Teenus ja tehniline lahendus on dokumenteeritud.
• Süsteemi kood on vabalt ligipääsetav, täiendatav ning allalaetav.

Esitame töö etappidena, kus kõigepealt defineerime ära Minimum Viable Producti [1] ehk selle miinimumi, mis pakub kasutajale maksimaalset väärtust. See tähendab API loomist ning esmase kliendi loomist kõigile MVP-s defineeritud kasutajagruppidele. Seejärel realiseerime projekti inkrementide ehk tootearenduse sammudena, milles lisame uusi funktsionaalsusi. Ideaalis jõuame realiseerida kõik sammud, kuid kuna teeme nimetatud tööd antud ajaraamis ja koosseisus esmakordselt, siis võtame vabaduse ka realiseerida korralikult niipalju, kui jõuame projekti käigus ära teha.

Võimalik, et meie lõpptulemus erineb mõnes osas esitatud analüüsist. Seda olenevalt sellest kui edukalt meil õnnestub plaanitud funktsionaalsusi realiseerida. Erisusi plaanime käsitleda vastavas 'post production' jaotuses, kus loendame ka projektist kogunenud peamised õppetunnid.

Analüüs valmis (1) metoodika abil, vt lähemalt projekti metoodikate sektsioonist.

Minimum Viable Product definitsioon

Kasutaja

• Kasutaja saab süsteemi logida ning välja logida
• Kasutaja saab lisada uue kellakarbi
• Kasutaja saab lisada uue kella kellakarpi
• Kasutaja saab muuta kella infot kellakarbis
• Kasutaja saab näha ülevaadet oma karpidest
• Kasutaja saab muuta kellakarbi seadeid
• Kasutaja saab kustutada kella karbis
• Kasutaja saab kustutada kellakarbi

Administraator

• Näeb autoriseeritult logisid
• Tootja
• Saab lisada kontaktandmeid
• Saab kontaktandmeid muuta

Inkrement #1

Kasutaja

• Näeb karbilt saabunud veateateid.
• Saab kellakarpe juhtida.

Administraator

• IP-aadresside järgi ülevaadet, millistes riikides karpe kasutatakse (üldised arvandmed).
• Karpidesse paigaldatud kellade nimistut (ilma muude kasutajaandmeteta).
• Näeb kasutajate statistikat.

Tootja

• Saata personaalseid teateid kellakollektsionääridele.

Inkrement #2

Kasutaja

• Saab saata teate tootjale.
• Näeb tootja vastust.
• Näha karbi seisundit, kas karp on hetkel wifiga ühendatud või mitte.

Administraator

• Näha kellade üleskeeramise mehhanismide arvnäitajaid (madalaim kiirus, keskmine kiirus, tippkiirus; samuti liikumise suundade arvnäitajaid).
• Näeb tegevuste ajalugu kliendist.

Tootja

• Saab lugeda kasutaja teadet.
• Saab vastata kasutajale.

Hooldaja

• Saab info hooldamist vajavate kellade kohta.

Inkrement #3

Kasutaja

• On ehitatud keeletugi.

Tootja

• On ehitatud keeletugi.

Hooldaja

• On ehitatud keeletugi.

Inkrementid valmisid (1) metoodika abil, vt lähemalt projekti metoodikate sektsioonist.

Kasutatud kirjandus ja allikad

1. Albahari, Joseph, Albari, Ben 2017. C# 7.0 in A Nutshell. Sebastopol: O’Reilly
2. MariaDB Foundation. MariaDB. Kättesaadav:https://mariadb.org/
3. Martin, Robert 2018. Clean Architecture. Boston: Pearson Education