Vastus (03.03.2024 18:48):

1. Üks võimalik viis, kuidas tarkvara tükeldada. Tükeldamine on vajalik tarkvara keerukusega toimetulekuks ja töö paremaks organiseerimiseks.
2. Ülevaade võimalikest mudelitest, mida saab kasutada tarkvara kirjeldamiseks. Ka agiilne süsteemiarendus ütleb, et modelleerimine on vajalik. Tuleb luua mudeleid, millest on kasu, mitte linnukese pärast. Erinevates olukordades, võib olla kasu erinevatest mudelitest. Selleks, et osata otsustada, kas mingit tüüpi mudel mingis olukorras sobib või mitte, tuleb esmalt neid mudeli tüüpe teada. Samuti tuleb arendajal osata aru saada nõuetest ja seega ka mudelitest, mida võidakse kasutada nende nõuete väljendamiseks.
   • Inimesed, kes ei näe oma tulevikku arendajana (analüütikud, andmeteadlased, ettevõtjad, projektijuhid, raamatupidajad jne), võivad tulevikus vabalt sattuda infosüsteemi/tarkvara tellija rolli või kaasatud tulevase kasutaja rolli, kellega tellimuse koostamisel ja süsteemi arendamisel konsulteeritakse. Eriti riigiasutuste puhul on kogu rahastamise loogika selline, et enne arenduse algust soovitakse sõlmida võimalikult täpne leping selle kohta, mida süsteem peab tegema. Seega on kõigepealt vaja teha terve süsteemi analüüs ja sisuliselt tähendab see, et arendus vähemasti algab koskstiilis (edasine arendus võib kuid ei pruugi toimuda iteratiivselt). Tark tellija peab teadma, milliseid süsteemianalüüsi mudeleid saab koostada ning ta peab oskama neid mudeleid lugeda. Kaasatud kasutaja peab samuti oskama mudeleid lugeda. SIIN on üks eestikeelne intervjuu targa tellija olulisuse kohta.
3. Puhta koodi põhimõtted on universaalsed ja kehtivad ka mudelite ning andmebaasi disaini puhul.
4. Andmebaasis kitsenduste loomine on üks kaitsva programmeerimise meetod. Kaitsev programmeerimine üritab tagada koodi toimist ka ettenägematute asjaolude ilmnemisel ja see aitab parandada süsteemi käideldavust ja turvalisust. Siin on raamat, mis on pühendatud kaitsvale andmebaasi programmeerimisele.

Kirjutan järgnevalt täpsemalt ja toon näiteid.

1. Tänapäeval on üheks lööksõnaks e "kuumaks teemaks" mikroteenuste arhitektuur. See tähendab, et tarkvara peaks koosnema üksteisest võimalikult vähe sõltuvatest "tükkidest" e teenustest, mida saaks arendada ülejäänud "tükkidest" võimalikult sõltumatult, mida saaks kerge vaevaga asendada uue realisatsiooniga ja mida ei peaks (palju) muutma, kui mõnes teises "tükis" midagi muutub. Iga funktsionaalse allsüsteemi saaks realiseerida mikroteenusena. Selle funktsionaalse allsüsteemi teenindatava registri saaks realiseerida rakenduse andmebaasina.

Mikroteenused üritatakse luua üksteisest võimalikult sõltumatuna, eelistades dubleerimist üksteisest ilmutatud viisil sõltumisele. Andmebaaside mõttes tähendaks see, et erinevate teenuste andmebaasides dubleeritaks põhiandmeid (master data) nagu andmed klientide, toodete ja teenuste kohta ja klassifikaatoreid. Kommentaariks ütlen, et see võib tunduda teenuse autonoomsuse mõttes ahvatlev, kuid andmete dubleerimine tähendab suuremat tööd nende sünkroniseerimiseks (nii suuremat tööd arendajatel selle realiseerimiseks/testimiseks kui ka suuremat koormust süsteemile läbiviimisel) ja suuremat võimalust vastuoluliste väidete registreerimiseks. Kas see on sobiv hind või mitte jäägu igaühe enda otsustada ja kindlasti sõltub ka oludest. (Eesti) Riigi infosüsteemide kohta ütleb avaliku teabe seadus selge sõnaga: "§ 43 3.   Andmekogu asutamine (2) Keelatud on asutada ühtede ja samade andmete kogumiseks eraldi andmekogusid."

Põhiobjektidest lähtuv allsüsteemide leidmine on üks võimalik viis mikroteenuste kindlaks määramiseks ja põhiobjekti elutsüklist lähtuv funktsionaalsuse leidmine on üks võimalik viis selle teenuse funktsionaalsuse tuvastamiseks.

Kui soovida luua mikroteenused võimalikult autonoomsena ja vajadusel dubleerida andmeid erinevate teenuste andmebaasides, siis saaks teenused luua põhiobjektidele, mis vastavad transaktsioonilistele andmetele ning põhiandmetele ja klassifikaatoritele vastavaid andmeid erinevates andmebaasides dubleerida. Siin on näide hotelli infosüsteemi põhiobjektidest andmete liigituse järgi.

2. See on väga vähetõenäoline, et mõni ettevõte kasutab süsteemide kirjeldamiseks just sellist dokumendi struktuuri nagu on aineprojektis. Kuid see, et mingil määral kasutatakse modelleerimist ja mudeleid ning mõnda antud projekti mudeli tüüpidest, on väga palju tõenäolisem.

Hea allikas, kust saab lugeda erinevate aineprojekti mudelitüüpide kohta, on:

• Larman, C., 2013. Applying UML and patterns : an introduction to object-oriented analysis and design and iterative development, Prentice Hall. 703 p.
  • Seda saab ka lugeda O'Reilly digitaalse platvormi kaudu elektrooniliselt.
  • Kuidas kasutada O'Reilly digitaalset platvormi?

See raamat on pühendatud objektorienteeritud analüüsile ja disainile (eesmärgiga luua objektorienteeritud programmeerimiskeeles tarkvara), kuid räägitakse ka arendusprotsessist. Mudelite koostamine ei ole mitte kuidagi vastuolus iteratiivse arendamisega. Lihtsalt mudeleid ei looda ühekorraga, vaid neid luuakse ja täiendatakse järk-järgult erinevate iteratsioonide käigus. Raamatus kirjutatakse muuhulgas põhjalikult:

• klassidiagrammidest, mida kasutades luuakse valdkonnamudeleid (domain model),
  • Kontseptuaalne andmemudel ja valdkonnamudel on sugulased ja kontseptuaalse andmemudeli loomise võtted ning mustrid on kõik kasutatavad ka valdkonna klassidiagrammide koostamiseks. Sama kehtib ka antimustrite kohta, mis esitavad esmapilgul häid lahendusi, mis hiljem viivad probleemideni. Need klassidiagrammid on omakorda sisendiks tarkvaraklasside leidmisele (nii nagu kontseptuaalne andmemudel on sisendiks tabelite leidmisele),
• seisundidiagrammidest,
• tegevusdiagrammidest,
• kasutusjuhtude mudelist,
• paketidiagrammidest,
  • Saab kasutada arhitektuuri kirjeldamiseks.
• süsteemi operatsioonide lepingutest
  • Need on sarnased andmebaasi operatsioonide lepingutega. Süsteemi operatsioonid kirjeldavad teenuseid, mida funktsionaalsed allsüsteemid (tarkvara) pakuvad pädevusaladele (lõppkasutajatele). Andmebaasi operatsioonid kirjeldavad teenuseid, mida andmebaasi alamosad (registrid) pakub funktsionaalsetele allsüsteemidele (tarkvarale).
  • Nii nagu süsteemi operatsioonide lepingutest tekivad tarkvara klasside meetodid, tekivad andmete muutmise operatsioonide lepingutest andmebaasiserveris talletatud rutiinid (funktsioonid ja protseduurid).
  • Operatsioonide lepingud võiksid huvi pakkuda ka seetõttu, et need lähtuvad lepingprojekteerimise (design by contract) põhimõttest. See põhimõte töötati välja seoses objektorienteeritud programmeerimiskeelega Eiffel ning esitab tarkvara elementide käitumist viisil, mida ideaalis saaks hiljem kasutada tarkvara kontrollimiseks või koodi genereerimiseks. Sellel teemal mõtlejaid on teisigi (vaadake History alamosa Larmani raamatu süsteemi operatsioonide lepingute peatükist) ja nende idee on kasvanud välja arvutiteaduse (computer science) ringkondadest.

Järgnev raamat argumenteerib, miks kontseptuaalse andmemudeli ja andmebaasi disainimudeli loomine ei ole ka agiilse andmebaasi arenduse mõttes ajaraisk, vaid igati kasulik ettevõtmine.
Burns, L., 2011. Building the Agile Database. How to Build a Successful Application Using Agile Without Sacrificing Data Management, Technics Publications. 276 p.

CRUD maatrikseid on arvutiteaduses üritatud kasutada süsteemide struktuuri leidmiseks ja see on huvitav uurimissuund (vaadake näitena seda artiklit ja ka seda).

Tüüpiliselt kulub tarkvara hooldamisele igal aastal 15–20% tarkvara loomiseks tehtud kulutustest. Seega tarkvarale, mis on olnud kasutusel 10 aastat, on hooldamiseks kulunud kaks korda rohkem raha kui algseks loomiseks.  Edukaid süsteeme hooldatakse tavaliselt 10 kuni 20 aastat. Täpsed, kooskõlalised ning süsteemi tegelikku seisu peegeldavad mudelid aitavad tarkvara hooldusega tegelejatel (kes võivad, kuid ei pruugi, olla süsteemi loojad) tarkvarasüsteemist (sealhulgas andmebaasist) aru saada.

Tarkvara ja andmebaas peavad ajaga kaasas käima – evolutsioneeruma. Tarkvara/andmebaas pole nagu kivi, mis on miljoneid aastaid ühesugune, vaid nagu elusloodus, mis peab kohanduma ja muutuma. Muudatuste tegemisele aitab kaasa kvaliteetse dokumentatsiooni olemasolu.

3. Lugege näiteks siit, kuidas peaagu igale koodi halvale lõhnale vastab mingi analoogiline probleem seoses infosüsteemi/tarkvara mudelitega. Samamoodi esinevad andmebaasis ja tekitavad sellest arusaamisel, õppimisel, hooldamisel ja edasiarendamisel probleeme näiteks halvad andmebaasiobjektide nimed, kasutama andmebaasiobjektid, ebatäpsed kommentaarid, üleliigne dubleerimine ja järjekindlusetus disainiotsuste tegemisel.

Veel mõtteid dokumenteerimise vajalikkuse kohta

1. Dokumenteerimine aitab süsteeme edasi arendada. Viimasel ajal kaitstakse üha rohkem lõputöid, kus üksinda või rühmas arendatakse edasi mingit tarkvara (näiteks erinevad ülikooli õppesüsteemid), mida eelnevad üliõpilased on juba oma lõputöödes arendanud. Kuulates 2023. aasta kevadel selliste lõputööde kaitsmisi oli esinemisest esinemisesse korduv väide, et eelmine tegijate rühm ei olnud oma tööd piisavalt dokumenteerinud (sh polnud kirja pandud nõudeid ja kirjeldatud loodud tabeleid), mistõttu kulus väga palju (liigselt palju) aega süsteemi eelmise versiooni arenduskeskkonnas ülespanekule ja sellest arusaamisele ning vastavalt jäi loodetust vähem aega süsteemi edasiarendamisele.
   • Kaks tsitaati lõputöö ülesandepüstitusest - järjekorras kolmas tarkvara tegijate meeskond hakkas tarkvara nullist ümber tegema. Nad kirjutasid: „Eelmise projektiga tegelenud tiimid hakkasid kohe arendama, millest tulenevadki praeguse lahenduse vead ning vajadus projekti ümbertegemisele.“ Veel lisasid nad: "Arenduse käigus paneme suurt rõhku koodi dokumenteerimisele mis oli eelnevate lahenduste puhul väga suureks probleemiks." Eelmised tegijad hakkasid kohe suure hooga arendama, kuid lõpuks polnud ei korralikult toimivat tarkvara, ega ka korralikku dokumentatsiooni selle kohta.
   • Veel üks eluline näide. Tootmisettevõte tahab oma töö efektiivsemaks muutmiseks võtta kasutusele tehisintellekti, mis kliendi hinnapäringu alusel koostab automaatselt hinnapakkumise ja tootmise plaani. Tehisintellekt vajab oma tööks andmeid. Andmed tulevad andmebaasist. Info andmebaasi ülesehituse kohta (mis andmed on mis tabelites ja veergudes) on andmebaasi tegija peas. Enne kui saab süsteemi arendamisega pihta hakata tuleb see info peast kätte saada ning ilmutatult kirja panna.
2. Dokumenteerimine aitab tagada süsteemide turvalisust. Eesti infoturbestandard esitab nõuded ning juhised organisatsiooni infoturbe halduse süsteemi käivitamiseks, rakendamiseks, käigushoiuks ja täiustamiseks. Eesti avalikke ülesandeid täitavad organisatsioonid peavad E-ITSi nõudeid täitma, eraettevõtted võivad neid täita. Teiste sõnadega e-riigi süsteemides peab igal juhul E-ITSi nõudeid järgmima. E-ITS kirjeldab turvameetmed, mis jagunevad põhimeetmeteks ja standardmeetmeteks. Põhimeetmeid tuleb rakendada igal juhul, sest see on absoluutne miinimum mida turvalisuse tagamiseks teha. Standardmeetmete rakendamiseni jõudmine tagab suurema turvalisuse ja nende rakendamiseni jõudmine peaks olema iga organisatsiooni eesmärk. E-ITS pakub etalonturbe süsteemi, kus väljapakutud meetmed on jagatud erinevatele teemadele vastavatesse moodulitesse.
   • Moodulirühmas "Kontseptisoonid ja metoodikad" olevas moodulis "Tarkvaraarendus" on üks standardmeede "Detailne tarkvara dokumentatsioon". Meetme kirjelduses tuuakse välja, et tarkvara kohta peab olema üksikasjalik ja põhjalik dokumentatsioon ning loetletakse selle dokumentatsiooni minimaalselt nõutavad osad. Ühtlasi rõhutatakse, et dokumentatsiooni detailsus peab olema piisav, et nõutava tasemega tehniline ekspert suudaks dokumentatsioonile tuginedes tarkvaratoote halduse ja arendamise üle võtta. Samuti tuleb valida selline tarkvaraarenduse metoodika, mis näeb ette dokumentatsiooni loomise.
   • Moodulirühmas "Rakendused" olevas moodulis "Tellimustarkvara arendus" on üks standardmeede "Tellimustarkvara nõuete põhjalik dokumenteerimine". Meetme kirjelduses tuuakse välja vajadus dokumenteerida nii funktsionaalsed kui ka mittefunktsionaalsed nõuded, kusjuures mittefunktsionaalsete nõuete juures nimetatakse ka nõuete liigid, mis tuleb kindlasti välja tuua. Samuti rõhutatakse, et "pärast tarkvaramuudatuste ja funktsionaalsete uuendite installimist kontrollitakse nõuetele vastavust ning vajadusel uuendatakse tarkvara nõuete dokumentatsiooni."
   • See, et taolistest asjadest turvalisuse tagamise standardis kirjutatakse, on loogiline, sest üks kolmest infoturbe põhikomponendist on käideldavus. Käideldav süsteem on ettenähtud ajal ettenähtud mahus kättesaadav. Selle tagamiseks tuleb süsteemi pidevalt hooldada ja vajaduse tekkides edasiarendada ning selleks on omakorda vaja süsteemist detailideni aru saada (vt esimene mõte).
3. Dokumenteerimine aitab vältida pärandsüsteemidest (legacy system, taakvara) tulenevaid probleeme.  Riigi Infosüsteemi Ameti (RIA) küberturvalisuse 2022. aasta aastaraamatus kirjutatakse: "Taakvara vaevab paljusid pikka aega tegutsenud ettevõtteid ja asutusi. Näiteks ei pruugi kümme aastat tagasi arendatud süsteemi praegustel omanikel olla täielikku teadmist selle ülesehitusest ega funktsioonidest. Organisatsioonid muutuvad ajas, inimesed  vahetuvad ning pahatihti ei ole kunagi kasutusele võetud lahendused „järeltulijatele“ korralikult dokumenteeritud. Seetõttu pole sageli täpselt teada, millise doominoefekti võib ühe osa uuendamine kuskil süsteemi teises otsas kaasa tuua." Iga tarkvara, mida piisavalt pikka aega kasutatakse, muutub ühel hetkel taakvaraks.
4. Dokumenteerimine aitab kaasa taaskasutamisele. Erinevate Eesti riigiasutuste koostöös valminud tehisintellekti ja andmete valges raamatus aastateks 2024-2030 kirjutatakse: "Andmete taaskasutus saab toimida ainult siis, kui erinevate osapoolte poolt hallatavad andmed on standardiseeritud, korrastatud, kirjeldatud, avalikustatud, kontrollitud kvaliteediga ning varustatud andmete taaskasutust toetava dokumentatsiooni ja toega." Samas dokumendis kirjutatakse, et Eesti e-riigis ei ole sellega sugugi kõik korras, sest "vaid 8% riigiasutustest on juurutanud andmekirjelduse standardi, 28% on kaardistanud kõik oma andmed, põhiandmed on kaardistanud ja kirjeldanud 36% asutustest". Sama dokumendi kohaselt puudub 2023. aasta seisuga 58%-l asutustest täielik ülevaade oma andmestikest ja 55% asutustest ei uuenda ja avalikusta regulaarselt andmekirjeldusi.

Kokkuvõtteks, päriselu ei ole AINULT idufirmad. Nendes võibolla tõesti on eesmärk kiiresti midagi tööle saada, et enne konkurente turule jõuda. Kui firma jääb püsima, siis pigem varem kui hiljem tuleb hakata arvestama eelnevalt kirjeldatud probleemidega.