Rok Miklavˇciˇc
Opredelitev izhodiˇ sˇ c za digitalizacijo cerkvenih matiˇ cnih knjig
DIPLOMSKO DELO
UNIVERZITETNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN INFORMATIKA
Mentor : izr. prof. dr. Damjan Vavpotiˇ c
Ljubljana, 2021
besedilo, slike, grafi in druge sestavine dela kot tudi rezultati diplomskega dela lahko prosto distribuirajo, reproducirajo, uporabljajo, priobˇcujejo javnosti in pre- delujejo, pod pogojem, da se jasno in vidno navede avtorja in naslov tega dela in da se v primeru spremembe, preoblikovanja ali uporabe tega dela v svojem delu, lahko distribuira predelava le pod licenco, ki je enaka tej. Podrobnosti licence so dostopne na spletni strani creativecommons.si ali na Inˇstitutu za intelektualno lastnino, Streliˇska 1, 1000 Ljubljana.
Izvorna koda diplomskega dela, njeni rezultati in v ta namen razvita program- ska oprema je ponujena pod licenco GNU General Public License, razliˇcica 3 (ali novejˇsa). To pomeni, da se lahko prosto distribuira in/ali predeluje pod njenimi pogoji. Podrobnosti licence so dostopne na spletni strani http://www.gnu.org/
licenses/.
Besedilo je oblikovano z urejevalnikom besedil LATEX.
Vrsta naloge: Diplomska naloga na univerzitetnem programu prve stopnje Raˇcunalniˇstvo in informatika
Mentor: izr. prof. dr. Damjan Vavpotiˇc
Opis:
V okviru diplomske naloge najprej analizirajte obstojeˇce stanje na podroˇcju cerkvenih matiˇcnih knjig. Posebej se posvetite njihovi zgradbi oz. zgradbi v njih zapisanih podatkov. Nato kratko predstavite morebitne obstojeˇce infor- macijske reˇsitve in preuˇcite njihove pomanjkljivosti. Na tej podlagi opredelite izhodiˇsˇca za digitalizacijo, ki naj obsegajo pregled kljuˇcnih funkcionalnosti sistema, predlog podatkovnega modela, predlog programske arhitekture sis- tema in predlog kljuˇcnih informacijskih tehnologij. Na osnovi teh izhodiˇsˇc izdelajte prototip sistema in ga testirajte. ˇSe posebej se posvetite testira- nju zmoˇznosti oz. uspeˇsnosti prepisa obstojeˇcih podatkov matiˇcnih knjig v predlagan sistem. Rezultate diplomske naloge kritiˇcno ovrednotite.
Title: Defining the basis of parish registers digitalization Description:
As part of the diploma thesis, first analyze the current situation in the field of parish registers. Pay special attention to their structure, or the structure of the written data. Then briefly present any existing information solutions and examine their shortcomings. On this basis, define the starting points for digitization, which should include an overview of key system functionalities, a data model proposal, a system software architecture proposal, and a proposal for key information technologies. Based on these starting points, develop a prototype of the system and test it. Devote special attention to testing the
plomskega dela. Prav tako se zahvaljujem gospodu ˇzupniku Joˇzetu Miklavˇciˇcu za napotke pri analizi in dostop do matiˇcnih knjig.
Povzetek Abstract
1 Uvod 1
2 Analiza organizacije cerkvenih matiˇcnih knjig 3
2.1 Zgodovina matiˇcnih knjig . . . 3
2.2 Krstna knjiga . . . 4
2.3 Poroˇcna knjiga . . . 7
2.4 Mrliˇska knjiga . . . 11
2.5 Druge evidence . . . 13
2.6 Pogoste napake in pomanjkljivosti . . . 15
3 Analiza obstojeˇcih reˇsitev 17 3.1 Podatkovna struktura . . . 18
3.2 Pomanjkljivosti sheme . . . 24
3.3 Arhitekturne pomanjkljivosti . . . 25
4 Izbor tehnologij in orodij za razvoj 27 4.1 Arhitektura MVC . . . 28
4.2 REST API . . . 29
4.3 Node.js . . . 30
4.4 Express . . . 31
4.5 Angular . . . 31
4.8 Javascript . . . 33 4.9 Mocha in Chai . . . 33 4.10 Selenium . . . 33
5 Naˇcrtovanje 35
5.1 Namestitveni diagram . . . 36 5.2 Diagram primerov uporabe . . . 38 5.3 Naˇcrt strukture . . . 38
6 Razvoj prototipa 45
6.1 Streˇzniˇski del . . . 45 6.2 API in dostop do podatkovne baze . . . 47 6.3 Celni del . . . .ˇ 52 6.4 Predstavitev spletne aplikacije . . . 55
7 Testiranje 63
7.1 Testiranje API . . . 63 7.2 Testiranje komponent spletne aplikacije . . . 65 7.3 Testiranje na podmnoˇzici podatkov matiˇcnih knjig . . . 67
8 Sklepne ugotovitve 71
Literatura 75
kratica angleˇsko slovensko ACID atomicity, consistency, iso-
lation, durability
atomskost, skladnost, izo- liranost, trajnost
ANSI American National Stan- dards Institute
Ameriˇski drˇzavni inˇstitut za standarde
CORS cross-origin resource sha- ring
deljenje virov navzkriˇznega porekla
CSS Cascading Style Sheets prekrivni slogi
JS JavaScript JavaScript
JSON JavaScript Object Nota- tion
objektna notacija za Java- Script
HTML HyperText Markup Lan- guage
jezik za oznaˇcevanje nad- besedila
MVC model–view–controller model–pogled–krmilnik NPM Node Package Manager node paketni upravitelj RDBMS relational database mana-
gement system
relacijski sistem za upra- vljanje baz podatko
REST representational state transfer
predstavitveni prenos sta- nja
SKP standard classification of occupations
standardna klasifikacija poklicev
SQL Structured Query Langu- age
sestavljeni jezik za poi- zvedbe
UML Unified Modeling Langu- age
poenoteni jezik modelira- nja
URL Uniform Resource Locator enoliˇcni krajevnik vira
Naslov: Opredelitev izhodiˇsˇc za digitalizacijo cerkvenih matiˇcnih knjig Avtor: Rok Miklavˇciˇc
Cerkvene matiˇcne knjige predstavljajo pomemben del zgodovine Slovenije, vendar je dostop do teh podatkov trenutno zelo omejen in zapleten. Glavni rezultat diplomskega dela je uspeˇsno razvit prototip, ki obsega komponente spletne aplikacije za vnos zapisov matiˇcnih knjig s predlagano strukturo po- datkov. V zaˇcetnem delu smo opravili analizo trenutne organizacije cerkve- nih matiˇcnih knjig in obstojeˇcih reˇsitev, razvitih za digitalizacijo matiˇcnih knjig. Na podlagi analize smo razvili koncept podatkovnega modela. Po ra- zvoju komponent smo izvedli testiranje na konkretnih podatkih iz obstojeˇcih matiˇcnih knjig.
Kljuˇcne besede: matiˇcne knjige, aplikacija na eni strani, PostgreSQL, An- gular.
Title: Defining the basis of parish registers digitalization Author: Rok Miklavˇciˇc
Parish registers represent an important part of Slovenia’s history, but access to this information is currently very limited and complex. The main result of the thesis is the successfully developed prototype, which includes components of the web application, that allows users to enter parish registers with the proposed data structure. In the initial part of the thesis, we performed an analysis of the current organization of parish registers and existing solutions developed for digitization of the registers. Based on the analysis, we devel- oped the concept of a data model. After the development of the components, we performed testing on concrete data from existing parish registers.
Keywords: parish register, single-page application, PostgreSQL, Angular.
Uvod
Cerkvene matiˇcne knjige predstavljajo pomemben del zgodovine Slovenije, saj vsebujejo veliko podatkov o razvoju in propadu druˇzin [8]. ˇCedalje veˇc ljudi si ˇzeli odkriti del zgodovine svoje rodbine, a je dostop do teh podatkov trenutno zelo omejen in zapleten.
Medtem ko je digitalizacija s skeniranjem knjig potencialna reˇsitev, ˇse vedno ni popolna, saj mora ˇzupnijski upravitelj v iskanju zgodovine druˇzine ˇse zmeraj pregledati velike koliˇcine podatkov. Reˇsitev, ki je bolj smiselna, je sistem za vodenje matiˇcnih knjig, vendar pa se pri tem hitro pojavi ne- kaj teˇzav, kot nekonsistentna struktura podatkov in zapletenost relacij med osebami. Ravno zaradi teh problemov so bili dosedanji rezultati poskusov razvoja takih sistemov v praksi neuporabni.
Trenutno se na dnevni bazi ˇse vedno uporablja fiziˇcno vnaˇsanje podatkov v knjige, kljub temu da je Katoliˇska Cerkev okoli leta 2013 razvila lasten centralni pastoralni informacijski sistem PasIS, ki je namenjen preglednemu vodenju delovanja in poslovanja slovenskih katoliˇskih ˇzupnij, vendar se za- radi ˇze prej omenjenih problemov ne uporablja. Tako naˇsa reˇsitev koristi vsem ˇzupnijskim upraviteljem, ki si ˇzelijo olajˇsati zamudno delo z matiˇcnimi knjigami.
V zaˇcetnem delu smo opravili analizo trenutne organizacije cerkvenih matiˇcnih knjig (krstne, smrtne, poroˇcne in ostale evidence) in obstojeˇcih
1
reˇsitev. Izpostavili smo pomanjkljivosti sheme obstojeˇcega sistema PasIS in na podlagi analize razvili koncept podatkovnega modela.
Glavni rezultat je uspeˇsen razvoj prototipa, ki obsega komponente spletne aplikacije in uporabniku omogoˇca vnos zapisov matiˇcnih knjig s predlagano strukturo podatkov. Izvedli smo tudi avtomatsko testiranje tekom razvoja in testiranje na podmnoˇzici anonimiziranih zapisov obstojeˇcih knjig.
Prototip spletne aplikacije bi se lahko kasneje uporabil kot del informacij- skega sistema ter tako reˇsil probleme, ki so se pojavili pri dosedanjem razvoju podobnih sistemov.
Analiza organizacije cerkvenih matiˇ cnih knjig
Matiˇcne knjige so javne listinske knjige, ki nam za vsakega posameznika doloˇcene regije predstavijo njegove ˇzivljenjske dogodke in mejnike. Tako lahko najdemo vse bistvene podatke, kot so rojstvo, poroka in smrt ter ostale manj pomembne informacije in vpise, ki nam pomagajo pri postavitvi po- sameznika v ˇsirˇsi pogled druˇzbe. V celoti nam knjige omogoˇcajo izredno dober vpogled v demografske procese, spremembe v kulture skozi zgodovino in posamezne vidike vsakdanjega ˇzivljenja.
2.1 Zgodovina matiˇ cnih knjig
Matiˇcne knjige so nastale v bolj primitivnih oblikah kmalu po pojavu krˇsˇcanstva in se v nekaterih primerih ohranjale ˇcez celotni srednji vek. Bizantinski ce- sar Justinijan (527–567) je v 6. stoletju uvedel sistem sestavljanja listin ob porokah, vpisovanje umrlih v diptihe in zapisovanje vseh pomembnih oseb v nekrologe. Ti vpisi so tako predstavljali evidenco pripadnikov cerkvene obˇcine [2].
Obvezno vodenje rojstnih in poroˇcnih matiˇcnih knjig je uvedel tridentin- ski cerkveni zbor (1545–1563), podrobnosti vodenja so prepustili ˇskofijskim
3
sinodam. Vodenje mrliˇskih knjig je postalo obvezno leta 1614 s strani rim- skega obrednika, ki je tudi predpisal natanˇcen obrazec za vodenje vseh treh vrst matiˇcnih knjig.
V ˇcasu cesarice Marije Terezije je avstrijska drˇzava vzpostavila svojo vojaˇsko organizacijo. Evidence pripadnosti verskim skupnostim, ki so jih pridobili z uvedbo ˇstetja prebivalstva, so uporabili za vojaˇske in zdravstvene namene. Leta 1770 so izdali odlok za vodenje matiˇcnih knjig, pozneje pa so leta 1774 ukazali, da je potrebno matiˇcne knjige hraniti in jih zavarovati v primeru poˇzara.
Naslednik Cesar Joˇzef II. je s patentom leta 1784 predpisal vodenje matiˇcnih knjig tudi s strani drˇzave, vodenje je naloˇzil le katoliˇskim ˇzupnikom in ra- binom, ki so imeli kot vodje matiˇcnih knjig funkcijo pomoˇznega drˇzavnega organa [2]. Njihove knjige so bile edine, ki so imele javno verodostojnost.
Leta 1812 je bilo vodenje matiˇcnih knjig iz duhovniˇskih rok predano na ˇzupane, ki so vodili civilne matice do leta 1814, ko so vodenje znova prevzeli ˇzupniki. V nekaterih izjemah so vodenje matiˇcnih knjig med tem obdobjem opravljali tudi nekateri ˇzupniki. Drugiˇc so vodenje leta 1946 na obmoˇcju Slovenije prevzeli matiˇcni uradi, s tem pa se je prenehala pravna veljav- nost cerkvenih matiˇcnih knjig. Vodenje knjig se na strani cerkve ˇse vedno nadaljuje, vendar sluˇzijo le za lastne potrebe cerkve in ne zajemajo vsega prebivalstva na obmoˇcju ˇzupnije.
2.2 Krstna knjiga
Krstna knjiga je zapisana v tabelariˇcni obliki in ima naslednje rubrike (slika 2.1 in slika 2.2):
1. Zaporedna ˇstevilka krsta: vse krste, ki so bili opravljeni na obmoˇcju ˇzupnije, vpisujemo z arabskim ˇstevilom. Ker so zaporedna ˇstevila, zapisujemo brez pike za ˇstevilom. Krˇsˇcence, ki domujejo v naˇsi ˇzupniji, krˇsˇceni pa so bili v drugi, vpiˇsemo z ravno ˇcrtico
”-“ ali pa s poˇsevno ˇcrtico
”/“.
2. Leto, mesec, dan in kraj rojstva: zapisujemo v vrstnem redu leto, mesec in dan. Letnico zapiˇsemo s ˇstevilom, mesec z besedo in dan s ˇstevilom s piko. ˇCe je kraj rojstva porodniˇsnica, vpiˇsemo kraj, ulico in hiˇsno ˇstevilko, ni potrebe po zapisu ˇzupnije. Ce pa je kraj rojstva izvenˇ porodniˇsnice, vpiˇsemo kraj, ulico, hiˇsno ˇstevilko in ˇzupnijo.
3. Leto, mesec, dan krsta in ˇzupnija krsta: zapisujemo v vrstnem redu leto, mesec in dan. Letnico zapiˇsemo s ˇstevilom, mesec z besedo in dan s ˇstevilom s piko. ˇZupnija naj se vpiˇse tudi, ko gre za domaˇco ˇzupnijo.
4. Ime krˇsˇcenca: ime naj se vpiˇse, kakor je zapisano v rojstnem listu, ˇce je imen veˇc, zapiˇsemo vse. Lahko se doda ˇse svetniˇsko ime zavetnika v oklepaju ali pa loˇceno z vejico.
5. Zakonski status starˇsev ob rojstvu in spol otroka: zakonski stan oznaˇcimo s poˇsevno ˇcrtico
”/“. V rubriki zakonski oznaˇcimo otroke cerkveno poroˇcenih starˇsev. Cerkveni zakon se dokaˇze s poroˇcnim listom, druˇzinsko knjiˇzico ali pa se ga ugotovi na podlagi matiˇcnih knjig.
V rubriki nezakonski oznaˇcimo otroke, ki so se rodili neporoˇcenim starˇsem, niti cerkveno niti civilno. Sem spadajo otroci, ki se rodijo v izvenzakonski skupnosti, kot tudi otroci, katerih starˇsi ne ˇzivijo sku- paj ali pa se oˇce ni vpisal v rojstni list otroka.
V rubriki civilno zakonski oznaˇcimo otroke starˇsev, ki priloˇzijo le civilni poroˇcni list.
Ravno tako kot pri rubrikah zakonskih stanov se v polju spola otroka oznaˇci s poˇsevno ˇcrtico
”/“.
Ce se cerkveno poroˇˇ cena zakonca loˇcita, se otrok, rojen v 300 dnevih po loˇcitvi, zapiˇse kot zakonski, drugaˇce kot nezakonski.
6. Priimek, ime, poklic in vera starˇsev: ˇce nosi otrok priimek po oˇcetu, se oˇcetov priimek zapiˇse z velikimi ˇcrkami, podobno velja za posvojene otroke. Ce je oˇˇ ce znan, vendar je otrok nezakonski in nosi priimek
po materi, se oˇcetov priimek zapiˇse z obiˇcajnimi ˇcrkami, materin pa z velikimi.
Ce sta starˇsa poroˇˇ cena cerkveno ali civilno, se pri materi najprej napiˇse njen dekliˇski priimek, nato pa
”r.“ in njeno ime.
V primeru dolgih poklicnih naslovov poklice napiˇsemo v skrajˇsani obliko, vendar jih ne skrajˇsujemo.
Ko gre za posvojenega otroka, je potrebno vpisati imena posvojiteljev ter, ˇce je tako tudi v civilnih matiˇcnih knjigah regije, tudi naravne starˇse.
7. Kraj in ˇzupnija domovaliˇsˇca starˇsev: naveden toˇcen naslov domovaliˇsˇca starˇsev, ali pa le matere, ˇce otrok ˇzivi pri materi. Ko je domovaliˇsˇce v drugi ˇzupniji, se navede tudi tujo ˇzupnijo.
8. Datum in kraj rojstva starˇsev in datum ter kraj poroke: podatki vse- bujejo dan, mesec, leto in kraj, isto velja za civilne poroke, vendar pred datumom napiˇsemo
”.civ“, da je pozneje moˇzen vpis cerkvene poroke.
9. Priimek, ime in poklic botrov
10. Priimek, ime in sluˇzba krstitelja: vpiˇsejo priimek in ime krstitelja ter njegovo sluˇzbo (ˇzupnik, ˇzupnijski upravitelj, kaplan, profesor itd.), ˇce je krstitelj iz druge ˇzupnije, se vpiˇse tudi kraj opravljanja sluˇzbe.
11. Prostor za opombe (birma, poroka, pozakonitev, posvojitev, smrt . . . ):
vpiˇsemo, kdaj je krˇsˇcenec prejel sveto birmo, sklenil zakonsko zvezo s kom in kje, izstop iz katoliˇske cerkve, ponovni sprejem v cerkev, smrt, razglasitev niˇcnosti cerkvenega zakona in podobno.
Vpisuje se tudi uradna spremeba imena in priimka, vkljuˇcno z datu- mom, krajem in ustanovo, ki je spremenila ime ali/in priimek.
Slika 2.1: Prva stran krstne matiˇcne knjige
Slika 2.2: Druga stran krstne matiˇcne knjige
Na vrhu obeh strani knjige se vpiˇse letnica vpisovanja in zaporedna ˇstevilka strani.
2.3 Poroˇ cna knjiga
Poroˇcna knjiga je zapisana v tabelariˇcni obliki in ima naslednje rubrike (slika 2.3 in slika 2.4):
1. Zaporedna ˇstevilka poroke: vse poroke, ki so bili opravljeni na obmoˇcju ˇzupnije vpisujemo z arabskim ˇstevilom. Ker so zaporedna ˇstevila, zapi-
sujemo brez pike za ˇstevilom. Poroke, ki so bile po predhodni pripravi v domaˇci ˇzupniji z odpustnico opravljene v drugi ˇzupniji, vpiˇsemo z ravno ˇcrtico
”-“ ali pa s poˇsevno ˇcrtico
”/“.
2. Datum in ˇzupnija poroke: vpiˇsemo samo enkrat za oba poroˇcenca; v razpredelnici ˇzenina vpiˇsemo leto, mesec in dan, v razpredelnici neveste pa ˇzupnijo poroke. Poleg obvezne ˇzupnije poroke lahko navedemo tudi ime cerkve ali pa kraja.
3. Priimek, ime, poklic ter vera ˇzenina in neveste: kot poklic vpiˇsemo tistega, za katerega je oseba izobraˇzena, ne pa delo, ki ga trenutno opravlja. Pri vpisu veroizpovedu se lahko vpiˇse krajˇsava, npr.
”rkc“, ali pa
”kat.“
4. Datum in kraj rojstva ˇzenina in neveste: podatki se morajo ujemati z obstojeˇcimi cerkvenimi ali pa civilnimi dokumenti (krstni in rojstni list).
5. Datum in ˇzupnija krsta ˇzenina in neveste: podatki se morajo ujemati z obstojeˇcim krstnim listom.
6. Kraj in ˇzupnija bivaliˇsˇca ˇzenina in neveste: vpiˇse se trenutno domo- valiˇsˇce poroˇcencev, tudi pri zaroˇcencih, ki ˇze leto ali dve ˇzivijo skupaj na istem naslovu, ˇceprav imajo uradno bivaliˇsˇce drugje.
7. Stan ˇzenina in neveste: samski ali vdovski stan oznaˇcimo s poˇsevno ˇcrtico
”/“.
8. Priimek, ime, poklic ter vera starˇsev ˇzenina in neveste: podatki se mo- rajo ujemati z obstojeˇcimi cerkvenimi ali pa civilnimi dokumenti (krstni in rojstni list). Za imenom matere vpiˇsemo najprej okrajˇsavo
”roj.“ in nato njen dekliˇski priimek. Vpiˇsemo poklic, ki ga starˇsi opravljajo v ˇcasu poroˇcnih priprav.
9. Priimek, ime in poklic priˇce ˇzenina in neveste
10. Priimek ime in sluˇzba poroˇcitelja: vpisujemo v vrstnem redu priimek, ime in sluˇzba poroˇcevalca. Pri sluˇzbi se najprej navede temeljna sluˇzba (npr. ˇzupnik, ˇzupnijski upravitelj, kaplan itd.), nato pa ˇsele dodatna funkcija (npr. dekan).
V primeru, da poroˇca duhovnik s pooblastilom ˇzupnika, poleg njegovih podatkov v rubriki
”Listine“ vpiˇsemo pooblastilo ˇzupnijskega urada.
11. Listine: vedno se po istem vrstnem redu vpiˇse datum in ˇstevilko listin, ki smo jih zbrali v procesu priprave na poroko:
(a) zapisnik pred poroko;
(b) krstni in samski list ˇzenina (ˇce ni krˇsˇcen v domaˇci ˇzupniji);
(c) krstni in samski list neveste (ˇce ni krˇsˇcena v domaˇci ˇzupniji);
(d) sporoˇcilo oklicev;
(e) potrdilo vpisa v krstno knjigo ˇzenina (ˇce ni krˇsˇcen v domaˇci ˇzupniji);
(f) potrdilo vpisa v krstno knjigo neveste (ˇce ni krˇsˇcena v domaˇci ˇ
zupniji);
(g) birmanski list (ˇce je bil izdan posebej in ni bila birma v domaˇci ˇ
zupniji);
(h) samski list (ˇce je bil izdan posebej in ne ˇzivi v tej ˇzupniji);
(i) mrliˇski list (za vdovce oziroma vdove);
(j) sodba cerkvenega sodiˇsˇca;
(k) spregled;
(l) dovoljenje starˇsev (pri mladoletnih otrocih);
(m) dovoljenje ˇzupnika, ki je dal pooblastilo poroˇcevalcu.
Slika 2.3: Prva stran poroˇcne matiˇcne knjige
Slika 2.4: Druga stran poroˇcne matiˇcne knjige
Na vrhu obeh strani knjige se vpiˇse letnica vpisovanja in zaporedna ˇstevilka strani.
2.4 Mrliˇ ska knjiga
Mrliˇska knjiga je zapisana v tabelariˇcni obliki in ima naslednje rubrike (slika 2.5 in slika 2.6):
1. Zaporedna ˇstevilka cerkvenega pogreba: vse umrle, ki smo jih na obmoˇcju ˇzupnije cerkveno pokopali, vpisujemo z arabskim ˇstevilom. Ker so za- poredna ˇstevila, zapisujemo brez pike za ˇstevilom. Civilnih pogrebov ne vpisujemo v mrliˇsko knjigo. Ko gre za prekop in prenos ostankov, umrlega vpiˇsemo v mrliˇsko knjigo nove ˇzupnije, vendar brez zaporedne ˇstevilke in dodamo opombo, da gre za ekshuminacijo. ˇCe imajo ˇzupnije skupno pokopaliˇsˇce, ki leˇzi na obmoˇcju ene ˇzupnije, vsak ˇzupnik zapiˇse umrlega v lastno mrliˇsko knjigo z zaporedno ˇstevilko.
V primeru, da ˇzelijo svojci pokopati umrlega v tuji ˇzupniji, se z zapo- redno ˇstevilko zapiˇse v ˇzupniji pokopa, lahko pa tudi v ˇzupniji, kjer je ˇzivel, vendar brez zaporedne ˇstevilke.
2. Datum smrti oziroma pokopa: zapisujemo v vrstnem redu leto, mesec in dan. Letnico zapiˇsemo s ˇstevilom, mesec z besedo in dan s ˇstevilom s piko. Vsa polja je potrebno za datum pokopa in pogreba zapisati posebej, ˇcetudi leto ali mesec sovpadata.
3. Kraj in ˇzupnija smrti ter domovaliˇsˇce in ˇzupnijo umrlega: drˇzimo se vrstnega reda, in sicer naprej smrt, nato bivaliˇsˇce. ˇCe je kraj smrti v bolnici, vpiˇsemo ime kraja, ulice in hiˇsno ˇstevilko, v kraju z veˇc bol- nicami pa ˇse ime bolnice, podobno, ˇce je kraj smrti v domu starejˇsih obˇcanov. Pri bivaliˇsˇcu navedemo stalno bivaliˇsˇce pokojnega. V pri- meru, da je oseba imela stalno bivaliˇsˇce v tuji ˇzupniji, vpiˇsemo tudi naziv ˇzupnije.
4. Priimek, ime in stan umrlega: pri ˇzenskah, ki so bile poroˇcene, je po- trebno vpisati tudi dekliˇski priimek. Vpis poklica ni obvezen, vendar je priporoˇcljiv.
5. Priimek, ime in poklic starˇsev oziroma sozakonca umrlega: pri ne- poroˇcenih se vpisujejo podatki o starˇsih, pri poroˇcenih ali vdovcih pa podatki o sozakoncu.
6. Spol umrlega: s poˇsevno ˇcrtico
”/“ oznaˇcimo ustrezno polje.
7. ˇCas in kraj rojstva umrlega: vpiˇsemo jih na podlagi civilnega doku- menta, ˇce tega ni, vnesemo podatke, zabeleˇzene v eni izmed matiˇcnih knjig ali pa kot nam jih posredujejo sorodniki. ˇCe je bil pokojni rojen doma, vpiˇsemo natanˇcno lokacijo s hiˇsno ˇstevilko, drugaˇce ustreza tudi samo mesto oziroma vas, pomembno je vpisati tudi ˇzupnijo rojstva.
Pametno je vnesti tudi starost pokojnega v desni spodnji kot.
8. Vzrok smrti: vpiˇsemo na podlagi civilnega mrliˇskega lista, drugaˇce po izjavi domaˇcih.
9. Kdo mu je podelil zakramente in katere: zapiˇsejo se vsi zakramenti, prejeti s strani pokojnega. ˇCe je pred smrtjo prejel katerega od za- kramentov, vpiˇsemo ime in priimek delivca in njegovo sluˇzbo (ˇzupnik, ˇzupnijski upravitelj, kaplan itd.).
10. Priimek, ime in sluˇzba pokopovalca: ˇce pokopava ˇzupnik iz tuje ˇzupnije, navedemo tudi kraj opravljanja duhovniˇske sluˇzbe.
11. Pokopaliˇsˇce, na katerem smo pokojnega pokopali: ker je moˇzno, da imajo ˇzupnije veˇc pokopaliˇsˇc, vpiˇsemo kraj pokopa in ˇzupnijo.
Na vrhu obeh strani knjige se vpiˇse letnica vpisovanja in zaporedna ˇstevilka strani.
Slika 2.5: Prva stran mrliˇske matiˇcne knjige
Slika 2.6: Druga stran mrliˇske matiˇcne knjige
2.5 Druge evidence
Od ˇzupnije do ˇzupnije se vodijo razliˇcne dodatne evidence, vendar je nekaj takˇsnih, ki se vodijo v veˇcini ˇzupnij in so pomembne pri naˇsi analizi:
• Knjiga matiˇcnih sprememb: vpisujejo se vse spremembe, ki se zgodijo tekom ˇzivljenja posameznika (birma, poroka, izstop iz katoliˇske cerkve, ponovni sprejem v cerkev, smrt in podobno). Te spremembe statusa se pozneje prepiˇsejo tudi v posamezne knjige.
• Druˇzinska knjiga (Status animarum): vsebuje bogate in zgoˇsˇcene infor- macije o posameznih druˇzinah znotraj ˇzupnije. Vsebuje sledeˇce rubrike
o posameznih ˇclanih druˇzine (slika 2.7):
– kraj, hiˇsna ˇstevilka, hiˇsno ime in stan druˇzine;
– ime in priimek;
– kraj, dan, mesec in leto rojstva;
– leto svete birme, prve spovedi in prvega svetega obhajila;
– opravljanje vojaˇske dolˇznosti;
– dan, mesec in leto poroke;
– dan, mesec in leto smrti;
– opombe, kot so podatki ˇzenina/neveste, novo prebivaliˇsˇce in po- dobno.
V nekaterih ˇzupnijah se namesto druˇzinske knjige poˇcasi uveljavlja upo- raba druˇzinskih kartotek, ki poleg prej navedenih podatkov vsebujejo ˇse dodatne informacije o starˇsih in otroku. Druˇzinska prijavnica se izpolni, ko starˇsi vpiˇsejo otroka k verouku.
Slika 2.7: Druˇzinska knjiga
Kljub temu da posameznih dodatnih evidenc v sklopu tega dela ne na- meravamo voditi, je vredno ovrednotiti doloˇcene strukture, ki se pojavijo (npr. beleˇzenje sprememb podatkov osebe tekom ˇzivljenja) in jih uporabiti pri naˇcrtovanju in razvoju.
2.6 Pogoste napake in pomanjkljivosti
Pri analizi cerkvenih matiˇcnih knjig je potrebno omeniti tudi pogoste napake in pomanjkljivosti, ki vplivajo na samo strukturo podatkov. Tako kakor z vsemi viri informacij, ki so bili v zgodovini vodeni roˇcno brez dodatnih po- stopkov za zaznavanje in odpravljanje napak, je potrebno pri branju evidenc paziti na ˇcloveˇsko napako. Te napake je L. Henry leta 1967 razdelil na na- kljuˇcne, sistematiˇcne in selektivne [11]:
• Nakljuˇcne napake so najpogosteje krivda ˇzupnijskega upravitelja. Po- manjkljivosti potencialno nastanejo zaradi ˇzupnikove bolezni, starosti, pozabljivosti in nepoznavanja uredb, poslediˇcno so deloma ali popol- noma napaˇcno zapisani vpisi, kot so ime, priimek, zakonski stan, da- tumi, poklic itd.
• Sistematiˇcne pomanjkljivosti so povezane z naˇcinom vpisovanja podat- kov zaradi razliˇcnih ureditev v zgodovini. Kot primer lahko vzamemo vpise smrti otrok, ki jih v 18. in ˇse celo v 19. stoletju niso dosle- dno vpisovali niti v mrliˇske niti v rojstne matiˇcne knjige [11], ali pa pomanjkanje kraja rojstva v nekaterih ˇzupnijah v doloˇcenih obdobjih.
• Selektivne napake so pogosto povzroˇcene s strani posameznikov, ki doloˇcenih podatkov ne ˇzelijo zabeleˇziti. Tako so v doloˇcenem obdo- bju selektivno izpuˇsˇcali ime in priimek neizpraˇsanih babic, ki so po- magale pri porodu [11]. Kljub temu da ti podatki niso pomembni za rekonstrukcijo demografske slike ˇzivljenja posameznikov, ˇse vedno predstavljajo luknjo v analizi podatkov.
Pomembno se je zavedati tudi veˇcjih pomanjkljivosti vira informacij cerkve- nih matiˇcnih knjig, kot so omejenost na naselja znotraj ˇzupnije, neˇcitljiv roko- pis nekaterih ˇzupnijskih upraviteljev, razvoj jezika skozi leta ter poˇskodovani in izgubljeni zapisi.
Analiza obstojeˇ cih reˇ sitev
Ze od nekdaj obstaja potreba po pisarniˇskem pripomoˇˇ cku, ki bi standardiziral opravila vnaˇsanja podatkov cerkvenih dejavnosti. Prvi poskusi so se pojavili leta 1993, ko se je v nekaterih ˇzupnijah uporabljal program
”Zupnija“. Odˇ teh prvih korakov pa je bilo poenostavljanje dela na pleˇcih samih ˇzupnijskih upraviteljev. Zaradi ˇcedalje veˇcje potrebe po olajˇsanjem vodenju delovanja in poslovanja slovenskih katoliˇskih ˇzupnij je Katoliˇska Cerkev okoli leta 2013 razvila pastoralni informacijski sistem PasIS (videz programa na sliki 3.1 in 3.2). Poleg vodenja matiˇcnih knjig sistem ponuja tudi pregledne pastoralne evidence na podroˇcju ˇstevilnih pastoralnih dejavnosti [10]. Sistem je bil na zaˇcetku razdeljen na dva dela: raˇcunovodskega in pastoralnega, vendar je bil raˇcunovodski kasneje opuˇsˇcen [6]. Uporaba programa je z letom 2015 postala obvezna za vse upravitelje katoliˇskih ˇzupnij, vendar se v praksi sistem zaradi svoje zapletenosti in pomanjkljive implementacije v veˇcini ˇzupnij ne uporablja.
Zasnova PasIS temelji na principu druˇzine, ki je sestavni del neke ˇzupnijske skupnosti. Druˇzina vsebuje eno ali veˇc oseb, ki so same po sebi samostojni subjekt, ki sodeluje pri dejavnostih v ˇzupniji [10]. Ohranja se vse relacijske povezave med osebami, kar se lahko pozneje uporabi za izdelavo rodoslovnih dreves.
17
Slika 3.1: Videz programa PasIS (podatki so anonimizirani)
3.1 Podatkovna struktura
V okviru diplomskega dela smo preko ˇzupnije Kostanjevica na Krki, za po- trebe analize relacijske sheme obstojeˇce reˇsitve, pridobili dostop do sistema.
Pri uporabi programa smo omejeni na navadnega uporabnika, tako da do- stopa do sheme in logike podatkovne baze na ˇzalost nimamo. Poslediˇcno je v nekaterih primerih nemogoˇce vedeti, ali se omejitve podatkov nahajajo nepo- sredno na baznem nivoju, ali pa v poslovni logiki aplikacijskega nivoja. Tako smo z vzvratnim inˇzeniringom po najboljˇsih moˇceh ustvarili koncept relacij- ske sheme, ki jo informacijski sistem uporablja za shranjevanje druˇzin, oseb in dogodkov. Zavedati pa se moramo, da naˇsa interpretacija sheme ni idealna, saj je lahko ˇze preprost podatek, kot so kljuˇci razredov, v dejanski podat- kovni bazi drugaˇcen. Pri izdelavi sheme smo se osredotoˇcili le na podatke,
Slika 3.2: Obrazec vnosa nove osebe (podatki so anonimizirani)
ki so pomembni v kontekstu naˇsega diplomskega dela, ker informacijski sis- tem, poleg vodenja matiˇcnih knjig, ponuja ˇse mnogo drugih funkcionalnosti.
Tako smo izdelali shemo le za podatke druˇzine, njihove ˇclane in dogodke treh kljuˇcnih matiˇcnih knjig (krstna, poroˇcna in mrliˇska). Ostali dogodki, kot so prvo obhajilo, ne dodajo dodatne vrednosti in so izven obsega tega dela.
Na sliki 3.3 so prikazani kljuˇcni razredi sheme. Posamezni razredi so dodatno opisani v tabeli 3.1. Vsaka druˇzina ima vsaj enega ˇclana. ˇClan ima v druˇzini vlogo, hkrati pa je lahko v veˇc druˇzinah, vendar je lahko hkrati aktiven le v eni. Druˇzina ima doloˇcen naslov, na katerem ˇzivijo vsi ˇclani.
Oseba ima lahko v okviru osebnega lista doloˇcene dodatne podatke, kot so god, stan, poklic, izobrazba, veroizpoved, vzrok in kraj smrti, naslov rojstva ter ˇzupnija rojstva in prebivaliˇsˇca.
Ime razreda Opis razreda
Oseba Poleg osnovnih podatkov o osebi vsebuje ˇse po- datke o rojstvu, smrti in starˇsih.
OsebaProstiVnos Vsebuje podatke prostega vnosa, ki so neodvisni od razreda
”Oseba“.
God Vsebuje naziv in datum goda.
Stan Naziv osebnega statusa, v katerem je oseba (poroˇcen(a), samski(a), vdovec/vdova ipd.).
Poklic Naziv poklica, podatki iz ˇsifranta Statistiˇcnega urada RS.
Izobrazba Naziv izobrazbe, podatki iz ˇsifranta Statistiˇcnega urada RS.
Veroizpoved Nazivi vseh glavnih veroizpovedi v Sloveniji.
VzrokSmrti Naziv kljuˇcnih vzrokov smrti (bolezen, nesreˇca, starost ipd.).
KrajSmrti Naziv ustanove, kjer je oseba umrla.
Zupnija Nazivi vseh ˇzupnij v Sloveniji.
Posta Vsebuje poˇstne ˇstevilke in nazive vseh poˇst v Slo- veniji.
Naslov Vsebuje naziv naselja/ulice in obˇcino naslovov v Sloveniji.
DruzinskiList Med sabo povezuje veˇc oseb v druˇzino, vsebuje atribute kraja bivanja druˇzine in dodatne osnovne informacije.
Clan Vmesni razred med osebo in druˇzinskim listom.
VlogaClana Naziv vloge ˇclana v druˇzini (oˇce, mati ipd.).
Sodelujoc Vmesni razred sodelovanja med osebo in dogod- kom.
VlogaSodelujocega Naziv vloge sodelujoˇce osebe na dogodku (boter, ˇ
zenin, krstitelj ipd.).
Dogodek Generalni razred dogodka, vsebuje atribute, ki so v vseh otrocih razreda. Z njim predstavimo vse dogodke, ki se dogajajo v ˇzupniji (krst, poroka, pogreb ipd.).
Status Trenutni status vpisanega dogodka (napovedan, potrjen ipd.).
VpisMaticnaKnjiga Vsebuje atribute vpisa v matiˇcno knjigo, ko je do- godek vpisan.
Kraj Nazivi krajev v Sloveniji.
SluˇzbaUradne Naziv sluˇzbe uradne osebe, ki je sodelovala na do- godku (ˇzupnik, duhovnik, misijonar ipd.).
Krst Otrok razreda
”Dogodek“, vsebuje ˇse dodatne in- formacije o krstu.
Pogreb Otrok razreda
”Dogodek“, vsebuje ˇse dodatne in- formacije o pogrebu.
Poroka Otrok razreda
”Dogodek“, vsebuje dodatne infor- macije poroke, kot so osebni podatki ˇzenina in ne- veste ter informacije o civilni poroki.
Obcina Nazivi obˇcin v Sloveniji.
Tabela 3.1: Opisi razredov programa PasIS
Slika 3.3: Razredni diagram informacijskega sistema PasIS
Ker imamo veˇc dogodkov, smo doloˇcili generalni razred dogodka, potem pa smo zaradi atributov, ki so ekskluzivni za doloˇcen dogodek (npr.
”kr- stnoIme“ pri entiteti krsta), z generalizacijo doloˇcili otroke razreda dogodek.
Na vsakem dogodku je doloˇcena uradna oseba, ki ga izvaja. Dogodek je lahko tudi zapisan v matiˇcno knjigo, pri ˇcemer se mu doloˇci leto, zaporedna ˇstevilka in stran zapisa. Pri entiteti poroke lahko ˇse dodatno specificiramo civilno poroko.
Sistem na mnogih mestih uporabniku omogoˇca doloˇcitev relacij med objekti, hkrati pa roˇcno popravlja zapise pridobljene iz relacijskega objekta. Kot pri- mer lahko vzamemo sodelujoˇce osebe na dogodku. Uporabnik lahko izbere sodelujoˇcega, hkrati pa ˇse dodatno (neodvisno od izbranega objekta) doloˇci njegovo ime in priimek (slika 3.4 in 3.5). Taka funkcionalnost se pojavi pred- vsem na sodelujoˇcih osebah in naslovih. V shemi smo to prikazali z entiteto
”OsebaProstiVnos“, da smo se izginili nepreglednosti in nepotrebnim atribu- tom v entitetah.
Slika 3.4: Prosti vnos imena botra (podatki so anonimizirani)
Slika 3.5: Ime botra, ki je zapisano na osebnem listu (podatki so anonimizi- rani)
3.2 Pomanjkljivosti sheme
Shema ima sama po sebi mnogo pomanjkljivosti in prostora za izboljˇsavo:
• Pojavlja se podvajanje podatkov zaradi funkcionalnosti prostega vnosa, kljub temu da smo izbrali relacijo. Tako se pri spreminjanju podatkov objekta prosto vnesena polja ne spremenijo, kar vodi k nedoslednosti podatkov in pogostim napakam pri vnosu. Kot primer lahko vzamemo botra pri krstu. ˇCe smo se pri vnaˇsanju osebnega lista botra zmotili in napaˇcno vnesli njegovo ime, se bo to avtomatsko izpolnilo pri vnaˇsanju krsta. V primeru, da se kasneje ime na osebnem listu botra popravi, se to na vpisu krsta ne bo posodobilo.
• Pri vnosu osebe so obvezni podatki ime, priimek, datum rojstva, spol in stan osebe. V praksi se pogosto zgodi, da je zaradi pomanjkljivih starih zapisov datum rojstva neznan ali pa pomanjkljiv. Nepravilnosti so posledica pogostih napak, ki smo jih specificirali v sklopu 2.6.
• Vnaˇsanje naslovov in poˇst zunaj drˇzave Slovenije je glede na trenutno shemo nemogoˇce. Pogosto namreˇc pride do zapisov oseb, ki so opravile neko dejavnost na tujem naslovu, poslediˇcno moramo take podatke pri vnaˇsanju preprosto izpustiti, kar ponovno povzroˇci pomanjkljive zapise.
• Druˇzina je omejena na en naslov. Po tem bi lahko sklepali, da je po- trebno ˇclana, ki se je preselil na drug naslov, nastaviti kot neaktivnega in prestaviti v lastno druˇzino. V praksi se tako pogosto pojavijo dileme, na kateri naslov umestiti druˇzino, ˇse posebej pri vnaˇsanju podatkov matiˇcnih knjig za nazaj.
• Oseba je lahko aktivna le v eni druˇzini hkrati, pojavi se dvoumnost, v kateri druˇzini nastaviti osebo kot aktivno.
• Onemogoˇceno je brisanje oseb. V primeru, da se pri vpisu zmotimo in ˇzelimo osebo izbrisati iz sistema, je to nemogoˇce.
• Praktiˇcno nemogoˇce je ugotavljanje sorodstvenih razmerij. ˇZe pri pre- prosti relaciji, kot je stric poroˇcene osebe, moramo narediti prehod ˇcez tri druˇzine, da pridobimo druˇzino iskane osebe.
• Pomanjkanje funkcionalnosti vnaˇsanja veˇc porok.
• Vnaˇsanje podatkov za nazaj pod doloˇcenimi pogoji ni dovoljeno. Kot primer lahko vzamemo scenarij, kjer osebi vnesemo datum smrti, po- slediˇcno se onemogoˇci vnaˇsanje podatkov zakramentov. V procesu di- gitalizacije knjig se lahko proces vnaˇsanja podatkov zelo zaplete, saj moramo hkrati gledati tudi vrstni red vnaˇsanja.
Mnogi od teh problemov so se pojavili med poskusi vnosa podatkov in so poleg samega programa eni izmed kljuˇcnih razlogov za neuspeˇsnost vpeljave sistema v ˇzupnije.
3.3 Arhitekturne pomanjkljivosti
Aplikacija PasIS je izdelala kot namizna aplikacija v ogrodju Microsoft .NET Framework 2.0. Izdelava namiznih aplikacij sama po sebi ni problem, vendar pa se moramo zavedati mnogih pomanjkljivosti, ki se pojavijo pri razvijanju, vzdrˇzevanju in uporabi aplikacije:
• Podpora operacijskih sistemov: ogrodje .NET Framework 2.0. podpira samo okolje Windows, uporaba aplikacije v okoljih Linux ali pa macOS ni mogoˇca. Za razvoj v drugih okoljih je potrebna izdelava loˇcenih verzij, kar ˇse zaplete razvoj in vzdrˇzevanje.
• Nameˇsˇcanje: pred uporabo aplikacije mora uporabnik prenesti in na- mestiti aplikacijo na svojo napravo. Poleg tega aplikacija PasIS zahteva povezavo VPN, ki ˇse dodatno oteˇzi namestitev in uporabo.
• Posodobitve: vsaka najmanjˇsa posodobitev in popravek s strani razvi- jalca mora biti nameˇsˇcena na raˇcunalnik uporabnika, kar lahko povzroˇci teˇzave stabilnosti, uporabnosti in varnosti.
Izbor tehnologij in orodij za razvoj
Prototip, ki obsega komponente, bi bil razvit kot spletna aplikacija, saj s tem reˇsimo probleme arhitekturnih pomanjkljivosti aplikacije PasIS, ki smo jih navedli v podsklopu 3.3. Spletne aplikacije namreˇc delujejo na vseh napravah, ki uporabljajo moderne brskalnike, problemi namestitve in posodobitve same aplikacije so praktiˇcno odpravljeni, razvoj pa je hitrejˇsi in preprostejˇsi.
Ker ˇzelimo ponuditi uporabniku ˇcim bolj tekoˇco uporabo komponent, bi uporabili ogrodje Angular [5] za razvoj aplikacij na eni strani. Kot razvojno okolje bi izbrali Node.js (s pomoˇcjo Express.js) zaradi lahke skalibilnosti in usklajenosti programskega jezika Javascript v zalednem in ˇcelnem delu apli- kacije. Relacijske podatkovne baze bi bile razvite s sistemom za upravljanje z relacijskimi podatkovnimi bazami PostgreSQL.
Za avtomatsko testiranje tekom razvoja bi bilo najbolj smiselno upora- biti ogrodja za testiranje enot Mocha, Chai in Selenium. Tako bi se izognili roˇcnemu testiranju, ki je zamudno, najmanjˇsa napaka pri razvoju pa lahko pomeni sesutje velikega dela sistema. Potrebno bi bilo testiranje na pod- mnoˇzici konkretnih podatkih iz obstojeˇcih matiˇcnih knjig, saj lahko le tako pridobimo strukture in relacije, ki odraˇzajo realistiˇcne podatke. Ti bi bili anonimizirani, da se izognemo raznim zapletom krˇsenja varovanja osebnih
27
podatkov.
4.1 Arhitektura MVC
Arhitekturni vzorec MVC loˇci aplikacijo na tri glavne skupine komponent:
podatki, pogled in logiko aplikacije. Cilj loˇcitve aplikacije na ta naˇcin je odstraniti tesno grupiranje med komponentami. Uporabniˇske zahteve so preusmerjene na krmilnik, ki je odgovoren za delo z modelom za izvajanje uporabniˇskih akcij in pridobivanje rezultatov poizvedb [13].
Podrobnejˇsi opisi posameznih komponent:
• Model: v kontekstu aplikacije prestavlja stanje aplikacije in vsako po- slovno logiko ali operacije, ki jih aplikacija izvaja. Poslovna logika mora biti skupaj z implementacijsko logiko za ohranjanje stanja aplikacije za- jeta v modelu.
• Pogled: odgovori so za predstavitev vsebine uporabniku na voljo preko uporabniˇskega vmesnika. Logike naˇceloma ne vsebujejo, izjema velja le za logiko, ki je povezana direktno s predstavitvijo vsebine uporabniku.
• Krmilnik: odgovoren za ravnanje z interakcijami uporabnikov, sodeluje z modelom in izbere pogled, ki ga prikaˇze uporabniku. Tako v aplikaciji MVC pogled samo prikazuje informacije, krmilnik pa upravlja in se odziva na uporabnikov vnos in interakcijo [13].
Veˇcina aplikacij je zasnovana tako, da sprejme dohodno zahtevo, jo obdela in vrne odgovor. Tako lahko na sploˇsno krog informacij opiˇsemo z zanko na sliki 4.1 [4].
Slika 4.1: Zanka zahtev in odgovorov osnovne MVC arhitekture
4.2 REST API
REST je arhitekturni slog in ne strog protokol, API pa omogoˇca komuni- kacijo med aplikacijami. V primeru spleta je API naˇceloma zaporedje URL naslovov, ki se ob klicu na pravilen naˇcin s pravilnimi informacijami odzovejo s podatki.
Vodilna naˇcela REST-a [18]:
• Odjemalec–streˇznik: med odjemalcem in streˇznikom mora biti defini- rana jasno vidna meja.
• Brez stanja: vse operacije odjemalca in streˇznika morajo biti brez sta- nja, vsako potrebno upravljanje stanja pa mora potekati na odjemalcu in ne na streˇzniku.
• Predpomnilnost: vsi viri morajo omogoˇcati predpomnjenje, razen ˇce je izrecno navedeno, da predpomnjenje ni mogoˇce.
• Enotni vmesnik: viri bi morali biti enotno prepoznavni z enim samim URL-jem in samo z uporabo osnovnih metod omreˇznega protokola.
• Veˇcplastni sistem: omogoˇca, da je arhitektura sestavljena iz veˇc plasti z omejevanjem obnaˇsanja vedenja komponent.
• Koda na zahtevo: REST odjemalcem omogoˇca razˇsirjanje funkcional- nosti s prenosom in izvajanjem kode v obliki programˇckov in skript.
4.3 Node.js
Node.js je odprtokodno izvajalno okolje, ki omogoˇca ustvarjanje spletnega streˇznika in gradnjo spletnih aplikacij na njem. Node.js aplikacije so na- pisane v jeziku Javascript, platforma vsebuje vgrajeno HTTP streˇzniˇsko knjiˇznico, kar pomeni, da ni potrebno zaganjanje posebnega programa sple- tnega streˇznika [4].
Znaˇcilnosti Node.js:
• Asinhronost in dogodkovna vodenost: vse API knjiˇznice platforme so asinhrone, to pomeni, da streˇznik nikoli ne ˇcaka na podatke.
• Hitrost: knjiˇznica je zgrajena na pogonu Javascript V8, Node.js je bil zasnovan za optimizacijo pretoˇcnosti in razˇsirljivosti.
• Enoten jezik Javascript: porabimo manj ˇcasa za premikanje med jeziki, ko piˇsemo kodo tako na strani streˇznika kot na strani odjemalca.
• Eno niten, vendar razˇsirljiv: uporablja eno niten model z zanko dogod- kov. Mehanizem dogodkov pomaga streˇzniku, da se odzove na naˇcin, ki ne blokira in naredi streˇznik zelo razˇsirljiv.
• Brez medpomnjenja: aplikacije Node.js nikoli ne medpomnijo podat- kov, raje jih preprosto oddajajo v kosih.
• Npm: npm omogoˇca dostop do veˇc sto tisoˇc paketov za veˇckratno upo- rabo.
4.4 Express
Express je eno izmed najbolj priljubljenih spletnih ogrodij okolja Node.js in deluje kot osnova za mnoga ostala priljubljena Node.js ogrodja. Zagotavlja mehanizme za [3]:
• Upravitelje pisanja za zahteve z razliˇcnimi HTTP glagoli na razliˇcnih URL poteh.
• Zdruˇzevanje s prikazovalnimi pogoni, da bi ustvarili odzive z vstavlja- njem podatkov v predloge.
• Nastavljanje pogostih skupnih nastavitev spletnih aplikacij, kot so vrata za povezovanje in lokacije predlog, ki se uporabljajo za prikazovanje od- govorov.
• Dodajanje dodatne vmesne programske opreme za obdelavo zahtev v kateri koli toˇcki cevovoda za obvladovanje zahtev.
4.5 Angular
Angular je odprtokodno programsko inˇzenirsko ogrodje, ki se uporablja za iz- delavo spletnih aplikacij na eni strani in uporablja arhitekturo MVC. Ogrodje Angular poveˇze Javascript in HTML, Javascript sprejme uporabniˇski vnos in ga poˇslje Angular-ju, ki ga uporabi za spreminjanje HTML-ja [9].
Prednosti Angular-ja so dvosmerna vezava podatkov, direktive v datote- kah HTML, predloge, podpora testiranja enot in integracije ter zdruˇzljivost za mobilne naprave in namizne raˇcunalnike.
4.6 Bootstrap
Bootstrap je odprtokodno razvojno ogrodje na ˇcelnem delu za izdelavo sple- tnih strani in aplikacij. Ogrodje je zgrajeno na osnovi HTML, CSS in Java- script, glavni cilj pa je pomagati razvijalcem pri razvoju odzivnih spletnih
mest in aplikacij na veˇc napravah. Odziven dizajn namreˇc omogoˇca, da spletna stran zazna velikost in usmerjenost zaslona ter samodejno prilagodi zaslon [1], razvijalcem pa ni potrebno razvijati aplikacij za vsako napravo po- sebej. Bootstrap vkljuˇcuje komponente uporabniˇskega vmesnika, postavitve in Javascript orodja skupaj z ogrodjem za implementacijo.
4.7 PostgreSQL
PostgreSQL je napredni odprtokodni RDBMS s posebni poudarkom na razˇsirljivosti in skladnosti s standardi. PostgreSQL deluje na vseh glavnih operacijskih sis- temih, vkljuˇcno z Linuxom, razliˇcicami UNIX in Windows. Je skladen s stan- dardom ACID in podpira tuje kljuˇce, povezovanje tabel, poglede, trigger-je in shranjene postopke.
Nekaj najpomembnejˇsih funkcionalnosti PostgreSQL [17]:
• zdruˇzljiv z razliˇcnimi platformami, ki uporabljajo popularne jezike in vmesno programsko opremo;
• ponuja zaklepni mehanizem;
• podpora za nadzor nad soˇcasnostjo veˇc razliˇcic;
• funkcionalnost programiranja na strani streˇznika;
• skladno s standardom ANSI SQL;
• podpora omreˇzne arhitekture odjemalec–streˇznik;
• stanje pripravljenosti in visoka razpoloˇzljivost;
• objektno usmerjen in zdruˇzljiv z ANSI-SQL2008;
• podpora za JSON omogoˇca povezovanje z drugimi shrambami podat- kov, kot je NoSQL.
4.8 Javascript
Javascript je dinamiˇcen programski jezik, zasnovan za laˇzji in dostopnejˇsi ra- zvoj spletnih aplikacij. Je interpretiran jezik z objektno usmerjenimi zmoˇznostmi in se najpogosteje uporablja kot del spletnih strani, katere implementacije omogoˇcajo, da skripte na strani odjemalca komunicirajo z uporabnikom in ustvarijo dinamiˇcne strani.
4.9 Mocha in Chai
Mocha je Javascript testno ogrodje, ki deluje v brskalniku in na platformi Node.js. Glavna funkcionalnost je sposobnost, da asinhrono testiranje spre- meni v preprosto opravilo, kar nam omogoˇca fleksibilno in natanˇcno poroˇcanje.
Knjiˇznica Chai dovoljuje uporabniku, da uporablja vmesnik, ki mu naj- bolj ustreza:
”should“,
”expect“ ali pa
”assert“. Chai dodatek HTTP omogoˇca preprosto uporabo trditev o zahtevah HTTP, kar ustreza naˇsim potrebam.
Knjiˇznica ima veˇc vmesnikov, ki razvijalcem omogoˇcajo, da izberejo tistega, ki jim najbolj ustreza.
4.10 Selenium
Selenium je prenosno ogrodje za testiranje spletnih aplikacij. Ponuja orodje za predvajanje avtomatskih funkcionalnih testov, brez potrebe po uˇcenju testnih skriptnih jezikov. Na voljo je tudi testno domensko specifiˇcni jezik Selenese za pisanje testov v ˇstevilnih priljubljenih programskih jezikih, kot so Java, Python, C#, PHP, Ruby, Perl in .Net.
Naˇ crtovanje
Naˇcrtovanje sistema je proces razvoja abstraktnih modelov sistema, kjer vsak model predstavlja drugaˇcen pogled ali perspektivno sistema. Naˇcrtovanje nam pomaga pri razumevanju delovanja funkcionalnosti sistema in komuni- kaciji z ostalimi udeleˇzenci v razvoju. Po navadi za reprezentacijo sistema uporabimo kakˇsno izmed grafiˇcnih notacij, ki temeljijo na diagramih UML [14].
Modele lahko uporabimo med postopkom zajema zahtev, tekom naˇcrtovanja za opis sistema inˇzenirjem, ki razvijajo sistem, ter po implementaciji za do- kumentacijo strukture in delovanja sistema.
V naˇsem naˇcrtu bomo grafiˇcne modele uporabili kot:
• Naˇcin za diskusijo o predlaganem sistemu: namen modelov bo spodbu- diti in usmeriti razpravo. Modeli so lahko pomanjkljivi (dokler pokri- vajo kljuˇcne toˇcke razprave) in lahko uporabljajo nekatere od notacij neformalno.
• Naˇcin za dokumentacijo ˇze razvitega sistema: v tem primeru ni po- trebno, da so modeli popolni, saj se uporabljajo samo za dele sistema, ki jih ˇzelimo predstaviti. Kljub temu pa morajo biti modeli pravilni, saj ˇzelimo, da predstavljajo natanˇcen opis sistema, zahtevana je tudi pravilna notacija.
35
5.1 Namestitveni diagram
Diagram namestitve pomaga pri modeliranju fiziˇcnega vidika objektno usmer- jenega programskega sistema. Je strukturni diagram, ki prikazuje arhitekturo sistema kot distribucijo artefaktov programske opreme na tarˇce namestitve.
Artefakti prestavljajo konkretne elemente v fiziˇcnem svetu, ki so rezultat ra- zvojnega procesa. Z diagramom lahko predstavimo model strojne opreme, vkljuˇcno s programskimi komponentami.
Namestitveni diagram naˇse aplikacije je prikazan na sliki 5.1, njegove komponente so dodatno predstavljene v tabeli 5.1, povezave med komponen- tami pa v tabeli 5.2.
Slika 5.1: Namestitveni diagram
Komponenta Opis komponente
UporabniskiOdjemalec in spletni brskalnik
Uporabnik preko odjemalske naprave do- stopa do spletnega brskalnika, ki uporabniku prikaˇze vsebino dinamiˇcne spletne strani.
SpletniStreznik, Node.js in Express.js aplikacija
Okolje Node.js (sklop 4.3) je gostovano na streˇzniku, ki uporablja enega izmed podprtih operacijskih sistemov. Node.js skrbi tako za streˇzniˇski kot ˇcelni del aplikacije. Del oko- lja je spletno ogrodje Express (sklop 4.4), ki zagotavlja mehanizme za logiko delova- nja aplikacije, usmerjanje HTTP povezav na razliˇcnih poteh in dodajanje dodatne vmesne programske opreme za obdelavo zahtev.
PodatkovniStreznik Podatkovna baza PostgreSQL (sklop 4.7) go- stuje na podatkovnem streˇzniku, ki upora- blja eno izmed podprtih platform in ustreza minimalnim strojnim zahtevam.
GoogleMapsStreznik Za pridobivanje predlogov naslovov, se upo- rablja Google Maps Places API, ki gostuje na lastnem streˇzniku, komunikacija z njim pa poteka preko API gateway storitve.
Tabela 5.1: Komponente namestitvenega diagrama
Povezava Opis povezave
HTTP Komunikacije med spletnim brskalnikom in okoljem Node.js poteka preko HTTP proto- kola. Node.js okolje prejme HTTP zahtevo brskalnika, jo obdela in vrne HTTP odgovor.
Sequelize Za prenos podatkov med Express aplikacijo in podatkovno bazo PostgreSQL si poma- gamo s ORM knjiˇznico Sequelize, ki nam pre- tvori podatke relacijske baze v programerske objekte.
ngx-google-places- autocomplete
Ko ˇzeli Express aplikacija pridobiti pre- dlog za predvidevanje dokonˇcanja vnosa naslova, preko knjiˇznice ngx-google-places- autocomplete izvede HTTP klic na Google Maps streˇznik in v odgovoru pridobi poten- cialna predvidevanja.
Tabela 5.2: Povezave namestitvenega diagrama
5.2 Diagram primerov uporabe
Z diagrami primerov uporabe predstavimo interakcije med uporabniki in sis- temom. Diagram ne gre v podrobnosti in predstavlja zgolj pregled interakcij med akterji in sistemom na visoki ravni.
Na sliki 5.2 je prikazan diagram primerov uporabe interakcij naˇsega sis- tema in uporabnikov. V aplikaciji bo nastopal samo en tip uporabnika, in sicer ˇzupnijski upravitelj. Preko menija ima dostop do osnovnih funkcional- nosti: pregled oseb, pregled matiˇcnih knjig in dodajanje oseb in dogodkov.
Brisanje oseb in dogodkov razˇsirja pregled oseb in matiˇcnih knjig. Preko pre- gleda oseb in matiˇcnih knjig pa lahko uporabnik dostopa tudi do podrobnosti in urejanja oseb in dogodkov. Dodajanje in urejanje vsebuje funkcionalnost preverjanja konsistentnosti, obe funkcionalnosti pa komunicirajo tudi z ak- terjem
”API - Google Places“, ki ga uporabljata za pridobivanje predlogov naslovov.
5.3 Naˇ crt strukture
Strukturni modeli predstavljajo statiˇcno strukturo sistema in njegovih ele- mentov. Prikazujejo interakcijo med komponentami ali moduli, njihovo hi- erarhijo in medsebojno interakcijo [15]. Vkljuˇcujejo razrede, predmete, pa- kete ali module, fiziˇcna vozliˇsˇca, komponente in vmesnike [16]. Modeli nam
Slika 5.2: Diagram primerov uporabe
pomagajo pri zagotavljanju priˇcakovanega delovanja sistema in se pogosto uporabljajo pri dokumentiranju programske arhitekture programskih siste- mov.
Pri naˇsem naˇcrtu strukture se bomo osredotoˇcili le na zgradbo podatkov v obliki razrednega diagrama, ki se uporabi pri razvoju objektno usmerje- nih sistemov za prikaz razredov in asociacij med razredi. V njih prikaˇzemo razrede, njihove atribute, metode in relacije med razredi.
Diagram smo izdelali na osnovi razrednega diagrama informacijskega sis- tema PasIS (prikazan na sliki 3.3), ki smo ga izdelali v podsklopu 3.1. Pri tem smo se omejili le na podatke, za katere smo v poglavju 2 ugotovili, da so kljuˇci za digitalizacijo matiˇcnih knjig. Na sliki 5.3 so prikazane entitete, ki so zapisane v naˇsi podatkovni bazi in razmerja med njimi.
Slika 5.3: Razredni diagram
Posamezni razredi so dodatno opisani v tabeli 5.3. Kljuˇcni entiteti naˇsega sistema sta oseba in dogodek. Oseba ima poleg svojih atributov z asoci- acijami doloˇcen tudi neobvezen poklic, veroizpoved, spremembe in naslove aktivnosti. Dovoljeno je vpisati le en poklic, naˇceloma vpiˇsemo tistega, za
katerega je oseba izobraˇzena, ne pa delo, ki ga trenutno opravlja. V razred spremembe ob vsaki spremembi osnovnih podatkov osebe, njenih naslovov, poklica ali pa veroizpovedi shranimo kljuˇc spremembe, staro ter novo vre- dnost. Omejili smo se zgolj na te podatke, saj smo tekom analize obstojeˇcih zapisov ugotovili, da so kljuˇcni in da se v ˇzivljenju osebe spremembe izvajajo predvsem na njih. Oseba lahko sodeluje na veˇc dogodkih, dogodek pa ima vedno vsaj enega udeleˇzenca, doloˇceno pa mora imeti tudi ˇzupnijo, kateri pripada. Naslov ima lahko doloˇceno ˇzupnijo, vedno pa ima dodeljeno poˇsto.
Ime razreda Opis razreda
Oseba Vsebuje osnovne in kontaktne podatke osebe.
Sprememba Vsebuje nove in stare podatke, tip spremembe in datum ter uro spremembe, ki se izvedejo na osnov- nih podatkih osebe, njenih naslovih, poklicu ali pa veroizpovedi tekom ˇzivljenja.
Veroizpoved Nazivi vseh glavnih veroizpovedi v Sloveniji.
Poklic Naziv poklica, definirani po nacionalnem stan- dardu SKP-08.
RazmerjeOseb Vmesni razred sorodstvenega razmerja med dvema osebama.
Razmerje Tip sorodstvenega razmerja med dvema osebama (oˇce, mati, sin ipd.).
Aktivnost Vmesni razred aktivnosti med osebo in naslovom, aktivnost je lahko bivanje, smrt ali pa rojstvo osebe na nekem naslovu.
Naslov Vsebuje naziv, kraj in hiˇsno ˇstevilko naslova.
Posta Vsebuje poˇstno ˇstevilko in naziv poˇste.
Sodelovanje Vmesni razred sodelovanja med osebo in dogod- kom.
VlogaSodelujocega Naziv vloge sodelujoˇce osebe na dogodku (boter, ˇ
zenin, krstitelj ipd.).
Zupnija Nazivi vseh ˇzupnij v Sloveniji.
Dogodek Generalni razred dogodka vsebuje atribute, ki so v vseh otrocih razreda. Z razredom predstavimo osnovne podatke o dogodkih, ki smo jih predstavili v poglavju 2.
Krst Otrok razreda
”Dogodek“ vsebuje ˇse dodatne in- formacije o krstu.
Poroka Otrok razreda
”Dogodek“ vsebuje dodatne infor- macije poroke, kot so stan ˇzenina in neveste ter listine.
Pogreb Otrok razreda
”Dogodek“ vsebuje ˇse dodatne in- formacije o pogrebu, kot so podatki o smrti in sveti zakramenti, ki jih je prejel umrli.
Tabela 5.3: Opisi razredov sheme
Ker imamo veˇc ˇzivljenjskih dogodkov, smo doloˇcili generalni razred do- godka, potem pa smo zaradi atributov, ki so ekskluzivni za doloˇcen dogodek (npr. zakonskiStanStarsev pri entiteti krsta), z generalizacijo doloˇcili otroke razreda dogodek. Generalizacija je razmerje, v katerem eden izmed mode- lov (otrok) temelji na drugem modelu (starˇs). Otrok prejme vse operacije, atribute in razmerja, ki so definirani v starˇsu.
Relacije tipa mnogo proti mnogo smo predstavili z vmesnimi razredi, ki vsebujejo primarne kljuˇce od obeh tabel na relaciji. Tako lahko na primer oseba sodeluje na veˇc dogodkih, dogodek pa ima veˇc sodelujoˇcih oseb, kar prikaˇzemo z vmesnim razredom
”Sodelovanje“.
Diagram smo oblikovali glede na pomanjkljivosti, ki smo jih opisali v podsklopu 3.2, saj je bilo potrebno v naˇsem diagramu slabosti odpraviti in predlagati boljˇso alternativo. Reˇsitve za pomanjkljivosti so prikazane v tabeli 5.4.
Ime razreda Opis razreda
Podvajanje podatkov Odstranimo prosti vnos imena oseb, podatke vedno shranjujejo v razred
”Oseba“.
Pogosto manjkajoˇci podatki Poskrbimo, da atributi, kot je datum rojstva, niso obvezni, v primeru, da so pomanjkljivi ali manjkajoˇci.
Naslovi in poˇste zunaj drˇzave Slovenije
Shemi omogoˇcimo shranjevanje v obliki tujih naslovov, omogoˇcen prosti vnos.
Dilema naslova druˇzine Namesto fokusa na druˇzine, uporabimo raz- merja med osebami. Tako je predstavitev druˇzinskih razmerij bolj logiˇcna in ne pride do dilem pri umeˇsˇcanju druˇzin na naslov in pri vnaˇsanju podatkov za nazaj.
Aktivnost v druˇzini Z odstranjevanjem razreda druˇzin je lahko oseba v razmerju hkrati z veˇc osebami iz veˇc druˇzin.
Brisanje oseb Omogoˇcimo brisanje osebe in poskrbimo za vso potrebno logiko samodejnega odstranje- vanja odvisnih tabel.
Nepraktiˇcno ugotavljanje sorodstvenih razmerij
Prehodi ˇcez druˇzine niso veˇc potrebni, rela- cija je neposredno dostopna.
Veˇc porok Shema omogoˇca, da se oseba poroˇci veˇckrat.
Vnaˇsanje podatkov za nazaj Dovolimo prosto vnaˇsanje podatkov ne glede na vrstni red vnaˇsanja podatkov.
Tabela 5.4: Opisi razredov sheme
Razvoj prototipa
Po konˇcani analizi trenutne organizacije cerkvenih matiˇcnih knjig in ob- stojeˇcih reˇsitev, izboru tehnologij in orodij za razvoj ter naˇcrtovanju sistema, imamo vse potrebne sestavne dele za zaˇcetek razvoja aplikacije. Razvoj smo razdelili na:
• Streˇzniˇski del: odgovoren je za shranjevanje in organiziranje podat- kov. Komunicira s ˇcelnim delom ter poˇsilja in prejema podatke, ki se prikaˇzejo na spletni strani.
• Celni del: vkljuˇˇ cuje vse, kar uporabnik vidi na aplikaciji. Uporabniku prikazuje podatke in mu omogoˇca interakcijo.
6.1 Streˇ zniˇ ski del
Streˇzniˇski del temelji na izvajalnem okolju Node.js s pomoˇcjo spletnega ogrodja Express. Upravitelj paketov npm, ki je vkljuˇcen v okolju Node.js, omogoˇca preprosto upravljanje s paketi in moduli naˇse aplikacije. Vsaka Node.js apli- kacija vkljuˇcuje datoteko package.json, ki vkljuˇcuje razne metapodatke, vkljuˇcno s paketi, ki jih aplikacija potrebuje za izvajanje (slika 6.1).
45
Slika 6.1: package.jsonnaˇsega Node.js projekta
Vse zahteve do Express streˇznika gredo skozi vmesno programsko opremo, ki jo doloˇcimo v datoteki app.js. Vmesna programska oprema je v datoteki predstavljena z vrsticami app.use, vsaka od njih lahko zahtevo uporabi, ven- dar se vedno prenese na naslednjo, dokler ne doseˇze same logike aplikacije [4]. Na sliki 6.2 je primer vrstice app.use, ki prepreˇci napako CORS, ki se zgodi, ko ˇzeli spletna aplikacija na strani odjemalca posredovati zahteve na druge naslove.
Slika 6.2: Primer vmesne programske opreme app.use
6.2 API in dostop do podatkovne baze
Pred komunikacijo z bazo je potrebno vse zahteve, katerih naslov se zaˇcne z /api, preusmeriti v datoteko /app_api/routes/index, kjer se nahajajo vse naˇse poti za dostop do API-ja (slika 6.3). Krmilniki upravljajo z logiko aplikacije, usmerjanje pa usmeri zahteve URL na ustrezen krmilnik (slika 6.4).
Slika 6.3: Preusmeritev zahtev
Slika 6.4: Primer usmerjanja na ustrezne krmilnike
Za laˇzjo komunikacijo med okoljem Node.js in relacijsko podatkovno bazo PostgreSQL smo uporabili ORM knjiˇznico Sequelize [12]. Knjiˇznica nam pretvori podatke relacijske baze v programerske objekte, s katerimi lahko manipuliramo s programskim jezikom. Tako prihranimo ˇcas in se izognemo pisanju surovih SQL poizvedb.
6.2.1 Definiranje modelov
S knjiˇznico Sequelize lahko vnaprej definiramo modele, v naˇsem primeru bodo to entitete razrednega diagrama. Vsak model je definiran z imenom ter shemo, ki vsebuje lastnosti in razmerja. Na sliki 6.5 lahko vidimo mo- del poˇste, ki se ujema z razredom
”Poˇsta“ na razrednem diagramu v naˇcrtu strukture. Definirane ima atributeidPoste,postnaStinnazivPoste. Atri- but idPoste je tipa INTEGER in je unikaten, saj ga ˇzelimo uporabljati kot primarni kljuˇc.
Tip relacije med poˇsto in naslovom je ena proti mnogo. Naslov pripada poˇsti, poˇsta pa ima veˇc naslovov, kar v Sequelize definiramo, kot je vidno na sliki 6.6.
Slika 6.5: Model poˇste
Slika 6.6: Definicija razmerja med poˇsto in naslovom
Za relacije tipa mnogo proti mnogo potrebujemo vmesno tabelo, ki vse- buje kljuˇce in dodatne atribute relacije. Na sliki 6.7 je vidna definicija vme- sna tabela
”Aktivnost“ med osebo in naslovom v Sequelize. Oseba in naslov pripadata mnogim aktivnostim, aktivnost pa pripada tako osebi kot naslovu.
Slika 6.7: Relacija med poˇsto in naslovom
6.2.2 Komunikacija s podatkovno bazo
Krmilniki opravijo vso monotono delo, ki se pojavi ob obdelavi podatkov pri pisanju in branju podatkovne baze. Slika 6.8 prikazuje preprosto metodo vrniOsebePage, ki glede na parametre page inpageSize, pridobljene iz url povezave, vrne vse osebe na doloˇceni strani seznama. Iz baze preberemo obseg osebe, jih razvrstimo najprej po priimku, potem pa ˇse po imenu, nazaj pa vrnemo seznam oseb in celotno dolˇzino seznama oseb (za potrebe prikaza skupnega ˇstevila strani). Tako smo implementirali vse potrebne metode za delo z entitetami razrednega diagrama.
Slika 6.8: Metoda vrniOsebePage krmilnika osebe
6.3 Celni del ˇ
Angular nam omogoˇca razvoj dinamiˇcnih spletnih strani v programskem je- ziku TypeScript s pomoˇcjo oznaˇcevalnega jezika HTML in stilskega jezika CSS. Glavni del Angular aplikacije so komponente, ki upravljajo s pogledi in vsebujejo logiko aplikacije (primer dela komponente na sliki 6.9). Za usmerja- nje med komponentami smo ustvarili poseben modul, ki glede na pot naslova URL prikaˇze ustrezno komponento.
Slika 6.9: Pregled oseb
Aplikacija komunicira z bazo preko storitve, ki deluje v ozadju in ni direk- tno povezana z uporabniˇskim vmesnikom. Ob klicu metode iz komponente za pridobitev podatkov se izvede HTTP klic na podan naslov URL (primer klica vraˇcanja osebe na sliki 6.11), podatke prejmemo nazaj v obliki JSON (primer rezultata klica vraˇcanja osebe na sliki 6.10).
Slika 6.10: JSON rezultat klica vraˇcanja osebe (podatki so anonimizirani)
Slika 6.11: Metoda HTTP klica vraˇcanja osebe (podatki so anonimizirani)
6.4 Predstavitev spletne aplikacije
Uporabnik dostopa do veˇcine glavnih funkcionalnosti preko navigacijske vr- stice 6.12). Glavne funkcionalnosti spletne aplikacijo so sledeˇce:
• Pregled oseb: na zaslonski maski pregleda oseb lahko uporabnik pre- gleda osnovne podatke vseh oseb, ki so zapisane v bazi. Uporablja se ˇstevilˇcenje strani, za vsako osebo lahko uporabnik izbere funkcionalno- sti pregleda podrobnosti osebe in njenih dogodkov, urejanje osebe in njenih dogodkov ter brisanje osebe.
• Brisanje osebe: ob kliku gumba za brisanje na zaslonski maski pregleda oseb se uporabniku prikaˇze modalno okno za potrditev brisanja, po brisanju v podatkovni bazi se prikaˇze sporoˇcilo o uspeˇsnem brisanju osebe.
• Podrobnosti osebe: ob kliku gumba za podrobnosti osebe in dogodkov na zaslonski maski pregleda oseb je uporabnik preusmerjen na novo stran, kjer lahko pregleda podrobne podatke o osebi. Preko zavihkov se lahko premika med podatki osebe, razmerji osebe in dogodki osebe, na voljo je tudi urejanje podatkov osebe.
• Dodajanje/urejanje osebe: po uspeˇsnem dodajanju/urejanju se upo- rabniku prikaˇze sporoˇcilo, preusmerjen je na podrobnosti osebe, ki jo je dodajal/urejal.
• Pregled matiˇcnih knjig: uporabnik na strani izbere leto, v katerem so se izvedli dogodki. Prikaˇze se mu seznam, ki uporablja ˇstevilˇcenje strani.
Za vsak dogodek na seznamu nam je na voljo pregled podrobnosti do- godka in osebe, urejanje dogodka in osebe in brisanje dogodka.
Slika 6.12: Navigacijska vrstica
Funkcionalnosti, ki dodajo dodatno vrednost aplikaciji in se uporabljajo na veˇc komponentah, so sledeˇce:
• Validacija polj: v primeru, da je polje pravilno izpolnjeno, se obarva zeleno, ˇce pa niz vsebuje nedovoljen znak ali napaˇcno strukturo, se polje obarva rdeˇce.
• Iskanje krajev: ob vsaki spremembi polja kraja se izvede klic na Google Places API, ki vrne predloge krajev v Sloveniji. Ob izbiri kraja se izpolnijo tudi polja poˇste.
• Iskanje poˇst: ob vsaki spremembi polja naziva poˇste se iz podatkovne baze vrnejo predlogi poˇst. ˇSe vedno lahko definiramo svojo poˇsto (npr.
v primeru tuje poˇste), v tem primeru se doda v bazo. Ob izbiri poˇste se izpolnijo polja naziva poˇste in poˇstne ˇstevilke.
• Iskanje ˇzupnij: ob vsaki spremembi polja naziva ˇzupnije se iz podat- kovne baze vrnejo predlogi ˇzupnij. ˇSe vedno lahko definiramo svojo ˇzupnijo (npr. v primeru tuje ˇzupnije), v tem primeru se doda v bazo.
• Iskanje poklicev: ob vsaki spremembi polja poklica se iz podatkovne baze vrnejo predlogi poklicev, ki so definirani po nacionalnem stan- dardu SKP-08 [7]. ˇSe vedno lahko definiramo svoj poklic; ˇce tega v bazi ni, se doda v bazo.
• Iskanje oseb v razmerjih in vlogah: ob vsaki spremembi polja naziva ka- terega koli od udeleˇzencev v razmerju ali na dogodkih se iz podatkovne baze vrnejo predlogi oseb. Predloge sortiramo glede na spol osebe (npr.
za mati vrnemo samo osebe ˇzenskega spola) in ne vraˇcamo osebe, ki jo trenutno urejamo. Oseba ima lahko na dogodku samo eno vlogo, v primeru, da jo izberemo veˇckrat, se prikaˇze sporoˇcilo o napaki.
Od glavnih funkcionalnosti bomo v sklopu predstavitve aplikacije po- drobno opisali samo eno, in sicer
”podrobnosti osebe“. Vsi podatki na ma- skah so zgolj testni in ne predstavljajo podatkov obstojeˇcih zapisov. Preko zavihkov (slika 6.13) na strani se lahko uporabnik premika med:
Slika 6.13: Zavihki podrobnosti osebe
• Podatki osebe: prikazuje osnovne podatke osebe (slika 6.14), rojstva (slika 6.15), naslova bivanja (slika 6.16), naslova smrti, dodatne podatke (slika 6.17) ter osnovne podatke oˇceta in matere (slika 6.18). Ob kliku ikone poleg oˇceta ali matere je uporabnik preusmerjen na novo stran podrobnosti osebe. Uporabniku je na voljo tudi pregled sprememb podatkov, ki se zgodijo tekom ˇzivljenja posameznika (slika 6.19).
Slika 6.14: Osnovni podatki osebe
Slika 6.15: Podatki rojstva osebe
Slika 6.16: Podatki naslova bivanja
Slika 6.17: Dodatni podatki osebe
Slika 6.18: Osnovni podatki matere
Slika 6.19: Spremembe podatkov osebe
• Razmerja osebe: prikazuje osnovne podatke oseb, ki so v razmerju z osebo (slika 6.20). Ob kliku ikone razmerja poleg osebe je uporabnik preusmerjen na novo stran podrobnosti osebe.
Slika 6.20: Osnovni podatki bratovskega razmerja
• Krstom: prikazuje osnovne podatke o krstu osebe (slika 6.21) ter osnovne podatke vseh sodelujoˇcih (slika 6.22). Ob kliku ikone poleg sodelujoˇce osebe je uporabnik preusmerjen na novo stran podrobnosti osebe.
Slika 6.21: Osnovni podatki krsta
Slika 6.22: Osnovni podatki botra na krstu
• Porokami: uporabnik lahko iz spustnega menija izbere poroko osebe (slika 6.23). Prikaˇzejo se osnovni podatki o poroki (slika 6.24) in osnovni podatki vseh sodelujoˇcih. Ob kliku ikone poleg sodelujoˇce osebe je uporabnik preusmerjen na novo stran podrobnosti osebe.
Slika 6.23: Izbira poroke osebe
Slika 6.24: Osnovni podatki poroke
• Pogrebom: prikazuje osnovne podatke o pogrebu osebe (slika 6.25) in osnovne podatke vseh sodelujoˇcih. Ob kliku ikone poleg sodelujoˇce osebe je uporabnik preusmerjen na novo stran podrobnosti osebe.
Slika 6.25: Osnovni podatki pogreba
Uporabniku je na voljo tudi gumb za urejanje, ki ga preusmeri na novo stran urejanja trenutne osebe.
Testiranje
Cilji naˇsega testiranja so sledeˇci:
• Demonstrirati, da smo izdelali vse funkcionalnosti glede na zahteve, ki smo si jih zastavili. Za vsako funkcionalnost mora biti prisoten vsaj en test.
• Odkriti primere, kjer se programska oprema obnaˇsa nepravilno, ne- priˇcakovano ali pa ne v skladu z zahtevami.
• Odkriti obnaˇsanje sistema z veˇcjo koliˇcino obstojeˇcih podatkov iz matiˇcnih knjig.
• Izpostaviti primere zapisov, ki smo jih v naˇs sistem uspeˇsno zapisali, medtem ko jih obstojeˇce reˇsitve niso sposobne predstaviti.
7.1 Testiranje API
S knjiˇznicami Mocha in Chai smo tekom razvoja za vsako metodo na API- ju pisali teste, ki preverijo osnovno funkcionalnost. Tako smo se izognili roˇcnemu testiranju ob vsaki spremembi kode. Primer dela testa za dodajanje osebe in dogodkov lahko vidimo na sliki 7.1, kjer dodamo novo osebo in preverimo, ˇce se polja vrnjenega objekta ujemajo z dodanim.
63
Pred izvedbo skripte za testiranje nastavimo bazo na zaˇcetno stanje. Med izvedbo testov se v konzoli izpisuje povzetek vseh klicev na API, ˇcas trajanja posameznega klica in testa ter uspeˇsnost izvedenega testa (primer izvedbe testa za dodajanje osebe in dogodkov na sliki 7.2).
Slika 7.1: Del testa za dodajanje osebe in dogodkov
Slika 7.2: Izpis testa za dodajanje osebe in dogodkov
