|
|
|
### Rancangan Arsitektur
|
|
|
|
Modul validasi bertingkat merupakan sistem berbasis android dan web dengan megimplementasikan sistem ODK. Yang kemudian modul validasi bertingkat ini untuk diintegrasikan pada CAPI-STIS. Modul validasi bertingkat ini terdiri dari 4 aplikasi yang saling berintegrasi, keempat aplikasi ini adalah konverter xlsform menjadi xform, aplikasi ODK Collect/ klien, ODK Aggregate, dan server Notifikasi. Rancangan arsitektur sistem dapat dilihat dari 3 proses dibawah ini. Pada gambar terlihat bahwa tulisan yang berwarna hitam adalah fungsi yang telah ada pada ODK sebelum dilakukan penambahan modul validasi bertingkat dan warna merah adalah fungsi tambahan yang ditambahkan dalam modul validasi bertingkat. Berikut adalah 3 proses tersebut:
|
|
|
|
|
|
|
|
- Proses pembuatan dan pengunggahan xform
|
|
|
|
![Rancangan_Arsitektur_Part1_1_](/uploads/2bd09519dd50b6534e9ed07f7f3ac175/Rancangan_Arsitektur_Part1_1_.jpg)
|
|
|
|
|
|
|
|
Pada Gambar di atas, digambarkan arsitektur sistem mengenai pembuatan, pengunggahan xform, dan pengunduhan xform. Awalnya kuesioner dibuat dalam bentuk xlsform dengan format yang telah disesuaikan dengan modul validasi bertingkat. Setelah xlsform selesai maka xlsform diproses pada aplikasi konverter (flow 1). Hasil dari proses konverter adalah xform (flow 2). Xform ini kemudian diunggah ke ODK Aggregate (flow 3). Lalu jika ODK Collect ingin melakukan pencacahan maka ODK Collect tinggal melakukan pengunduhan xform dengan meminta ke ODK Aggregate (flow 4).
|
|
|
|
- Proses penyetoran data
|
|
|
|
![Rancangan_Arsitektur_Part2_1_](/uploads/ae979986bc7ce2411831f1797a05598b/Rancangan_Arsitektur_Part2_1_.jpg)
|
|
|
|
|
|
|
|
Pada Gambar di atas dijelaskan mengenai asitektur sistem usulan mengenai proses yang terjadi saat penyetoran data. Pada saat pencacah selesai melakukan pencacahan, maka pencacah dapat melakukan menyetoran data ke server ODK Aggregate (flow 5). Saat penyetoran data selesai ODK Aggregate menjalankan fungsi external service. Proses external service yang digunakan adalah external service yang tujuannya adalah server notifikasi (flow 6). Setelah data isian (berbentuk json) hasil external service Aggregate diterima oleh server notifikasi maka server notifikasi akan bertanya kepada Aggregate siapa yang berhak menerima notifikasi/ pemberitahuan mengenai penyetoran data ini (flow 7). Setelah server notifikasi menerima penerima notifiasi dari ODK Aggregtae maka Server notifikasi mengirim firebase notification message (fcm) ke ODK Collect penerima notifikasi (flow 8).
|
|
|
|
- Proses pembaruan data
|
|
|
|
![Rancangan_Arsitektur_Part3_1_](/uploads/e23668f7599529db0684015d8929f169/Rancangan_Arsitektur_Part3_1_.jpg)
|
|
|
|
|
|
|
|
Pada Gambar 52 menjelaskan mengenai arsitektur sistem usulan pembaruan data. Pada saat pengawas menerima notifikasi dari server notifikasi (pada arsitektur sebelumnya) pengawas terlebih dahulu harus mengunduh data isian dari ODK Aggregate (flow 9). Setelah mendapatkan isian maka pengawan akan melakukan pengecekan dan pengawasan isian. Setelah melakukan pengecekan dan pengawasan isian maka pengawas dapat memperbarui isian yang ada pada ODK Aggregate (flow 10). Saat isian diperbarui maka external service juga akan berjalan seperti sebelumnya. External service kemudian mengirim isian (dalam bentuk json) ke server notifikasi (flow 11). Setelah data external service diterima pada server notifikasi maka server notifikasi akan menanyakan ke Aggregate siapa yang berhak mengetahui bahwa isian tersebut telah diperbarui (flow 12). Setelah menerima penerima notifikasi maka server notifikasi akan mengirim firebase notification message (fcm) ke ODK Collect penerima.
|
|
|
|
|
|
|
|
### Rancangan basis data
|
|
|
|
|
|
|
|
Pada Basis Data ODK Aggregate diberikan pemodelan Entitty Rational Diagram, pada diagram ERD ini hanya ditampilkan tabel yang diubah atau ditampilkan dari basis data asli ODK Aggregate. Adapun perubahan atau penambahan tabel pada ODK Aggregate dapat dilihat sebagai berikut sebagai berikut:
|
|
|
|
|
|
|
|
![DatabaseODK_4](/uploads/a0c6f54032bd05fdeab2f2da01ce2501/DatabaseODK_4.jpg)
|
|
|
|
|
|
|
|
### Rancangan Antarmuka
|
|
|
|
|
|
|
|
- Tampilan pengaturan pengguna di ODK Aggregate
|
|
|
|
Salah satu fungsi pada modul validasi bertingkat pada ODK adalah penambahan atribut kelompok pengguna dan supervisor pengguna. Untuk melakukan pengaturan untuk hal tersebut dapat dilakukaan dengan membuka ODK Aggregate lalu menuju tab ‘Site Admin’ lalu masuk ke sub-tab ‘Permission’. Berikut rancangan antar muka sistem usulan untuk pengaturan kelompok pengguna dan supervisor pengguna:
|
|
|
|
|
|
|
|
![interface_6](/uploads/cd6472dc3292b06c700880025db79539/interface_6.png)
|
|
|
|
- Tampilan pengaturan constraint/ batasan di ODK Aggregate
|
|
|
|
Fungsi lainnya yang ditambahkan pada ODK Aggregate adalah penambahan constraint/batasan pada saat pengguna ingin mengakses, penyetor, dan memperbarui isian. Berikut rancangan antarmuka sistem usulun untuk pengaturan constraint/batasan pada ODK aggregate:
|
|
|
|
|
|
|
|
![interface_7](/uploads/6ea1c18034e7f7cd34d69d9ad857ac39/interface_7.png)
|
|
|
|
- Tampilan pengaturan kelompok pengguna di ODK Aggregate
|
|
|
|
Fungsi lainnya yang ditambahkan pada ODK Aggregate adalah penambahan kelompok pengguna. Kelompok pengguna mengatur role dan hak akses seorang pengguna. Berikut rancangan antarmuka sistem usulun untuk pengaturan kelompok pengguna pada ODK aggregate:
|
|
|
|
|
|
|
|
![interface_12](/uploads/d7f014176e3c0bff2e19c90a78c38f01/interface_12.png) |
|
|
|
\ No newline at end of file |