1. Problemos apibrėžimas
Reikalavimų specifikacijose dažnai apibrėžiamos reikšmių aibės (angl. enumerations) – baigtiniai leidžiamų reikšmių sąrašai – duomenų žodyne, o atskiri laukai į jas nurodo. Pasikartojanti situacija: laukui turi būti leidžiama naudoti tik esamos reikšmių aibės poaibį, pavyzdžiui, 5 iš 6 reikšmių, ir šis apribojimas galioja visada arba tik esant tam tikrai sąlygai.
Galimi du modeliavimo būdai:
- A variantas: apibrėžti naują, siauresnę reikšmių aibę, kurioje būtų tik leidžiamos reikšmės.
- B variantas: duomenų žodyne palikti nuorodą į visą reikšmių aibę, o apribojimą išreikšti atskira verslo taisykle.
Pasirinkimas turi pasekmių. A variantas didina beveik identiškų reikšmių aibių skaičių, sukuria sinchronizavimo naštą pasikeitus pradinei aibei ir paslepia semantinį faktą, kad reikšmės priklauso tai pačiai sąvokai. B variantas išlaiko vieną tiesos šaltinį, tačiau apribojimai išsklaidomi po atskiras taisykles, o įrankiai (kodo generavimo, validavimo) turi sujungti du artefaktus, kad nustatytų faktinę leidžiamų reikšmių aibę. Kyla klausimas: pagal kokį kriterijų naujos reikšmių aibės sukūrimas yra pagrįstas?
2. Pozicijos literatūroje
Nerasta šaltinio, kuris tiesiogiai nagrinėtų reikšmių aibių poaibius reikalavimų dokumentuose. Šis klausimas siejasi su gerai išnagrinėta potipių (subtyping) problema: kada apribota reikšmių aibė yra pakankamai savita, kad jai būtų suteiktas atskiras, pavadintas tipas?
Konceptualus duomenų modeliavimas. Hoffer, Ramesh ir Topi potipį apibrėžia kaip esybių tipo pogrupį, kuris organizacijai yra prasmingas ir kurio bendri atributai ar ryšiai skiriasi nuo kitų pogrupių. Taigi lemiamas kriterijus yra verslo prasmė, o ne vien tai, kad egzistuoja tam tikras apribojimas. Simsion ir Witt laikosi panašios pozicijos: potipiai įvedami verslui reikšmingoms klasifikacijoms, taip pat jie naudojami taisyklėms atvaizduoti ir sudėtingumui valdyti. Autoriai įspėja, kad nereikėtų kurti potipio kiekvienam apribojimui, ir pažymi, kad realizacijos lygmens modeliai paprastai neturėtų turėti potipių.
Tipų sistemos. Tipizuotose programavimo kalbose tas pats skirtumas yra įtvirtintas sintaksėje: apribotas reikšmių intervalas apibrėžiamas kaip bazinio tipo potipis su apribojimu, o ne kaip nesusijęs naujas tipas (Ashenden, nagrinėdamas VHDL potipius). Potipis paveldi bazinio tipo operacijas ir tapatybę; apribojimas dokumentuoja paskirtį ir leidžia ją tikrinti, tačiau nesukuria naujos sąvokos.
Schemos standartai. W3C XML Schema tą pačią idėją formalizuoja kaip tipo išvedimą taikant apribojimą (derivation by restriction): duomenų tipas gali būti susiaurinamas naudojant enumeration apribojimą, o išvestas tipas išlieka formaliai susietas su baziniu tipu. Pavadintas išvestinis tipas sukuriamas tada, kai apribojimas naudojamas pakartotinai; vienkartinis apribojimas išreiškiamas kaip anoniminis įterptinis tipas. UML pateikia lygiagrečius mechanizmus – generalizacijos rinkinius (generalization sets) ir powertype sąvoką, o OMG KDM taip pat traktuoja reikšmių sritis kaip atskirus pirmos klasės modelio elementus tik tada, kai jos atitinka prasmingas abstrakcijas.
3. Siūlomas sprendimas
Apibendrinus pirmiau aptartas pozicijas ir pritaikius jas reikalavimų inžinerijos praktikai, siūloma tokia sprendimo taisyklė:
- Numatytasis variantas – viena reikšmių aibė, apribojimą išreiškiant taisykle. Duomenų žodyno įrašas nurodo visą reikšmių aibę, o verslo taisyklė apibrėžia apribojimą, pavyzdžiui: „laukas X nepriima reikšmės Z“ arba „kai galioja sąlyga C, leidžiamos tik reikšmės {A..E}“. Tai atitinka tipo išvedimo taikant apribojimą principą ir išlaiko vieną tiesos šaltinį.
- Nauja pavadinta reikšmių aibė sukuriama tik tada, kai poaibis atitinka verslo prasmės kriterijų, kurį praktiškai galima išreikšti trimis sąlygomis:
- domeno ekspertai jau naudoja poaibiui pavadinimą savo komunikacijoje – tai yra sąvoka, o ne tik filtras;
- poaibis naudojamas daugiau nei vienoje specifikacijos vietoje;
- tikimasi, kad poaibis vystysis nepriklausomai nuo pradinės reikšmių aibės.
- Sukūrus naują reikšmių aibę, ji turi būti dokumentuota kaip išvesta iš pradinės reikšmių aibės, aiškiai nurodant ryšį „apribota [bazinės aibės] versija“. Tokiu būdu pasikeitus pradinei aibei galima inicijuoti išvestinės aibės peržiūrą. Reikėtų vengti nesusieto pradinės aibės kopijavimo.
- Sąlyginiai apribojimai (kai poaibis taikomas tik tam tikrame kontekste) visada turėtų būti B variantas. Sąlyga iš esmės yra kelių laukų ar kitų specifikacijos elementų sąveiką apibrėžianti taisyklė, todėl vien tipu jos išreikšti negalima.
Ši taisyklė leidžia reikšmių aibių skaičių sieti su verslo sąvokų skaičiumi, o ne su apribojimų skaičiumi, ir kartu išlaikyti kiekvieno apribojimo atsekamumą iki pradinės reikšmių aibės.
4. Apribojimai
Verslo prasmės kriterijaus taikymas yra ekspertinis vertinimas; trys praktiniai kriterijai sumažina, bet nepašalina dviprasmybės. Svarbus ir įrankių palaikymas: B variantas daro prielaidą, kad validavimo įrankiai gali sujungti duomenų žodyno ir taisyklių informaciją. Tai būdinga šiuolaikinėms schemų kalboms (XML Schema facets, JSON Schema enum ir sąlyginiai raktiniai žodžiai, UML OCL apribojimai), tačiau ne visoms reikalavimų valdymo aplinkoms.
Šaltiniai
- Hoffer, J. A., Ramesh, V., Topi, H. Modern Database Management. Pearson. Skyrius „The Enhanced E-R Model“ (supertipo ir potipio apibrėžimai).
- Simsion, G., Witt, G. (2005). Data Modeling Essentials, 3rd ed. Morgan Kaufmann. 4 skyrius „Subtypes and Supertypes“.
- Ashenden, P. (2008). The Designer’s Guide to VHDL, 3rd ed. Morgan Kaufmann. Potipių deklaracijos. Apžvalga: Enumeration type.
- W3C. XML Schema Part 2: Datatypes. Tipo išvedimas taikant apribojimą (derivation by restriction),
enumerationapribojimas. - OMG. Unified Modeling Language (generalizacijos rinkiniai, powertype).
- ISO/IEC/IEEE 29148 (2018). Requirements engineering (duomenų žodynas ir reikalavimų kokybės kontekstas).