Vastus (18.01.2024 00:44):

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.
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,
• 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 sell kohta.
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.