III-1
BAB III
ANALISIS DAN PERANCANGAN
Teori yang dijelaskan pada Bab II akan diterapkan pada analisis dan perancangan. Sub-bab yang ada akan menjelaskan model-model perancangan yang dipersiapkan untuk tahap implementasi.
3.1 Identifikasi Kebutuhan Perangkat Lunak
Bagian ini menjabarkan beberapa kebutuhan seorang ahli diet yang harus direalisasikan ke dalam Aplikasi Pelatihan Diet (APD). Kebutuhan ini diidentifikasi melalui wawancara langsung dengan seorang ahli diet.
3.1.1 Identifikasi Otomasi Aktivitas Pelatihan Diet
Dari hasil wawancara terhadap seorang ahli diet, didapatkan sekumpulan aktivitas pelatihan diet:
1. Klien dapat berkonsultasi dengan ahli diet kapan saja (tatap muka atau tidak). 2. Ahli diet melakukan pencatatan data-data kesehatan klien saat bertatap muka. 3. Ahli diet memberikan pesan personal yang berisi anjuran gaya hidup dan
catatan lain berkaitan dengan kesehatan klien.
4. Memberi tahu klien mengenai hasil pengukuran data kesehatan yang baru. Aktivitas ini akan menjadi fitur-fitur aplikasi yang dijalankan dengan format sedikit berbeda. APD akan menggunakan konsep diet genotip untuk membantu ahli diet mengontrol pola diet klien. Aktivitas pelatihan diet akan difasilitasi sehingga komunikasi antara ahli diet dengan klien akan menjadi lebih mudah.
3.1.2 Data Tubuh dan Data Kesehatan
Dari perpaduan penggunaan konsep diet genotip dan aktivitas pelatihan diet, terdapat dua jenis data yang akan digunakan, Data Tubuh dan Data Kesehatan. Data tubuh adalah karakteristik tubuh klien yang diperlukan untuk menjalankan pola diet genotip.:
2. Panjang kaki dan torso badan
3. Bentuk dan perbandingan jari manis dan jari telunjuk 4. Riwayat diri dan keluarga (penyakit kronis)
5. Pola sidik jari
6. Jenis bentuk tubuh, atau disebut juga dengan biometrik 7. Bentuk gigi dan rahang
Data kesehatan adalah nilai-nilai pengukuran yang dicatat oleh ahli diet pada saat bertatap muka dengan klien:
1. Berat badan (dalam kg), lingkar pinggang (dalam cm), dan Body Mass Index 2. Kadar lemak tubuh dan lemak viseral (dalam %)
3. Kadar air tubuh (dalam %)
4. Basal Metabolic Rate (dalam kal/hari)
5. Tekanan darah systole dan diastole (dalam mmHg) 6. Kadar kolesterol dan gula darah (dalam mg/dL)
Dalam mekanismenya, diet genotip hanya akan berpatokan pada data tubuh. Namun ahli diet akan terus memantau data kesehatan klien dan dapat memerintahkan klien untuk mengukur ulang data tubuh karena genotip klien bisa saja berubah.
3.1.3 Deskripsi Umum Sistem
Secara garis besar, aplikasi akan dioperasikan oleh 2 pengguna utama, ahli diet dan pelaku diet. Kedua pengguna dapat mengakses APD melalui web browser. Terkait dengan unsur keamanan, aplikasi memberlakukan penggunaan username dan
password untuk membatasi pihak yang berhak menggunakan aplikasi.
Kedua pengguna berinteraksi melalui APD. Ahli diet dapat memonitor kondisi kliennya secara teratur dan mudah, mengelola data kesehatan klien, dan berkomunikasi. Klien juga dapat memonitor data kesehatan dirinya serta berkomunikasi dengan ahli diet yang bersangkutan untuk berkonsultasi.
APD diletakkan pada sebuah server yang akan diakses oleh beberapa komputer melalui jaringan. Untuk media penyimpanan, APD membutuhkan sebuah database
untuk mengelola data pengguna aplikasi. Gambar III-1 menunjukkan skema implementasi APD.
Gambar III-1 Skema Implementasi Aplikasi Pelatihan Diet
3.1.4 Daftar Kebutuhan Perangkat Lunak
Tabel III-1 menunjukkan deskripsi kebutuhan fungsional APD. Kebutuhan fungsional akan direalisasikan menjadi fitur APD.
Tabel III-1 Daftar Kebutuhan Fungsional APD
ID Deskripsi Kebutuhan Fungsional
APD – F – 1 Seorang ahli diet dapat mendaftarkan seseorang menjadi klien baru pelaku diet. APD – F – 2 Seorang klien dapat menyimpan data tubuhnya ke dalam APD.
APD – F – 3 Seorang ahli diet dapat memantau data kesehatan dan perkembangan seorang klien. APD – F – 4 Seorang klien dapat memantau data kesehatannya sendiri serta melihat bagaimana
perkembangannya.
APD – F – 5 Seorang ahli diet dapat memperbarui data kesehatan dari seorang klien pada aplikasi setelah memperoleh data-data tersebut dari tatap muka secara rutin.
APD – F – 6 APD dapat memberikan tips-tips mengenai diet yang sesuai dengan klien yang bersangkutan, dengan memperhatikan data tubuh yang dia miliki.
APD – F - 7 Seorang klien dapat berlangganan tips-tips diet kepada APD yang akan dikirimkan secara berkala melalui email serta dapat menghentikannya kapan pun dia menginginkannya.
APD – F – 8 Seorang klien dapat mengukur seberapa sehatkah pola diet yang telah dia jalani selama ini melalui kalkulator diet yang disediakan oleh APD.
APD – F – 9 Antara ahli diet dengan klien dapat saling berkomunikasi secara personal. APD – F – 10 Klien dapat merubah profil dan konfigurasi pribadi yang disimpan dalam APD.
Sedangkan untuk daftar kebutuhan non-fungsional ditunjukkan pada Tabel III-2 Tabel III-2 Daftar Kebutuhan Non-Fungsional APD
ID Deskripsi Kebutuhan Non-fungsional
APD – NF – 1 Terdapat mekanisme keanggotaan yang cukup aman untuk membatasi aplikasi dari lingkungan luar.
APD – NF – 2 Antarmuka dari aplikasi harus bersifat konvensional, intuitif, dan mudah untuk digunakan.
Tabel III-20 Daftar Kebutuhan Non-Fungsional APD (lanjutan)
ID Deskripsi Kebutuhan Non-fungsional
APD – NF – 3 Aplikasi dibangun menggunakan kakas yang cukup umum, mudah untuk digunakan dan dipelajari, dan memiliki fitur atau komponen yang lengkap.
3.1.5 Model Use Case
Gambar III-2 menunjukkan diagram model Use Case sebagai hasil pengelompokkan dari requirement yang ada.
Gambar III-2 Diagram Use Case APD
Beberapa kebutuhan fungsional dikelompokkan ke dalam 8 buah use case. Deskripsi untuk masing-masing use case dijelaskan pada Tabel III-3 lengkap beserta nomor kebutuhan fungsional aplikasi yang direalisasikannya:
Tabel III-3 Deskripsi Use Case APD
ID Use Case Deskripsi Realisasi
Kebutuhan APD – UC – 1 Registrasi Seorang ahli diet mendaftarkan seorang
klien baru untuk program diet.
APD – F – 1 APD – UC – 2. Rekam Data Tubuh Seorang klien harus memasukkan data
tubuh untuk keperluan diet genotip.
APD – F – 2 APD – UC – 3. Ukur Pola Diet Klien mengukur pola diet yang dijalani
dan mengetahui kelebihan atau kekurangannya.
APD – F – 8
APD – UC – 4. Beri Tips Diet APD memberi tips kepada klien yang berisi saran olahraga, pola makan, serta resep masakan yang sesuai.
APD – F – 6 APD – F – 7
Tabel III–3 Deskripsi Use Case APD (lanjutan)
ID Use Case Deskripsi Realisasi
Kebutuhan APD – UC – 5. Perbarui Data
Kesehatan
Setelah berkonsultasi secara langsung dengan klien, seorang ahli diet memasukkan data kesehatan klien ke dalam APD untuk dipantau apakah diet yang dijalani telah memberikan hasil.
APD – F – 5
APD – UC – 6. Lihat Data Kesehatan Seorang ahli diet ataupun klien dapat memantau data kesehatan secara berkala dan melihat perkembangannya.
APD – F – 3 APD – F – 4 APD – UC – 7. Komunikasi Personal Ahli diet dan klien saling berkomunikasi
dengan mengirimkan dan menerima pesan pribadi melalui APD.
APD – F – 9
APD – UC – 8. Ubah Profil Klien dapat mengubah profil dan konfigurasi personal yang tersimpan.
APD – F – 10
3.1.6 Definisi Aktor Sistem
APD 2 aktor utama, ‘Ahli Diet’ dan ‘Klien’. ‘Pengguna Utama’ merupakan aktor hasil generalisasi kedua aktor sebelumnya atas beberapa aktivitas mereka yang serupa, seperti pada use case ‘Lihat Data Kesehatan’. Tabel III-4 memberikan deskripsi lebih lanjut untuk setiap aktor.
Tabel III-4 Definisi Aktor APD
No Aktor Deskripsi
1. Pengguna Utama Merupakan aktor general dari pengguna APD. Beberapa fitur APD dapat diakses oleh aktor ini. Untuk pengaksesan fitur yang lebih mengkhusus, aktor ini akan dispesialisasi ke dalam 2 jenis aktor, yaitu Klien dan Ahli Diet.
2. Klien Aktor ini berperan sebagai klien dari ahli diet. Mereka adalah pelaku program diet. Seorang klien dapat mengakses fitur utama pada APD yang bertujuan untuk membantu pola diet mereka. Aktor ini didaftarkan ke dalam APD oleh Ahli Diet. 3. Ahli Diet Merupakan penanggung jawab atas pelatihan diet yang
diberlakukan pada para kliennya. Aktor ini membimbing kliennya melalui pengawasan serta komunikasi personal yang dapat dilakukan via APD. Ahli Diet didaftarkan melalui jalur back-end APD oleh administrator.
3.1.7 Skenario Model Use Case
Penyusunan skenario pada aplikasi web tidak berbeda dengan aplikasi lainnya. Skenario tetap menunjukkan aksi apa yang dilakukan aktor dan reaksi apa yang diberikan sistem (APD) dalam tiap use case. Informasi mengenai pre-kondisi dan
atau dilakukan oleh aktor sebelum memulai skenario use case. Post-kondisi menyatakan kondisi atau status dari aktor setelah berada di akhir skenario.
Tabel III–5 adalah contoh format penulisan skenario untuk use case ‘Perbarui Data Kesehatan’.
Id Use Case : APD-UC-05
Nama Use Case : Perbarui Data Kesehatan
Tabel III-5 Skenario Use Case Perbarui Data Kesehatan
Aktor : Ahli Diet
Pre Kondisi : Aktor telah melakukan pertemuan langsung dengan klien untuk mengukur beberapa data kesehatan. Aktor telah melakukan login ke dalam sistem. Post Kondisi : Aktor menerima notifikasi bahwa ia telah berhasil menyimpan data-data
kesehatan ke dalam sistem.
Skenario Normal (APD-SN-05-01)
Aksi Aktor Reaksi Sistem
1. Memilih menu ‘Data Kesehatan Klien’
2. Menampilkan halaman pencarian klien. 3. Mencari dan memilih klien yang ingin
diperbarui data kesehatannya.
4. Menampilkan data kesehatan klien per tanggal pertemuan dengan ahli diet yang telah dilakukan. Jika tanggal pertemuan lebih dari satu, maka data kesehatan ditampilkan dalam beberapa halaman. 5. Memilih menu ‘Perbarui Data’.
6. Menampilkan halaman form data kesehatan. 7. Mengisikan data kesehatan kemudian menekan
tombol ‘Simpan’.
8. Memvalidasi data-data yang baru dimasukkan, seperti memeriksa kolom-kolom yang tidak boleh dikosongkan.
9. Jika data tidak valid, menampilkan notifikasi kesalahan pengisian data.
Jika valid, menampilkan notifikasi bahwa data telah tersimpan dan menampilkan halaman data kesehatan klien.
Untuk skenario use case selengkapnya tercantum pada Lampiran A – Dokumentasi Perancangan Lengkap APD.
3.2 User Experience Model
Bagian ini menunjukkan contoh pemodelan User Experience (UX) untuk salah satu
3.2.1 Model UX Use Case Perbarui Data Kesehatan
Berdasarkan skenario, use case ini melibatkan minimal 3 halaman, yaitu halaman utama APD, halaman daftar klien, serta halaman data kesehatan. Ketiga halaman ini memberikan tampilan isi berbeda yang cukup signifikan, sehingga mereka dikelompokkan dengan stereotip screen.
Setiap halaman dapat memiliki 3 jenis konten, yaitu konten statis, konten dinamis, dan masukan pengguna. Pada halaman daftar klien, konten judul dan cara penggunaan tergolong ke dalam konten statis. Untuk konten dinamis, halaman tersebut akan menampilkan daftar klien yang dapat berubah-ubah tergantung hasil pengambilan data dari database. Sedangkan masukan pengguna direpresentasikan dengan adanya tombol ‘Cari’ untuk mencari klien pada halaman tersebut.
Selain itu, APD harus memiliki tampilan khusus untuk menerima masukan pengguna. Stereotip form digunakan untuk merepresentasikan tampilan ini. Use case ini memerlukan 2 buah form. Sebuah form untuk menerima masukan pencarian klien pada halaman daftar klien dan sebuah form untuk memasukkan data kesehatan baru.
Beberapa screen compartment seperti header, footer, dan daftar menu utama akan diperlukan. Pada screen compartment, beberapa informasi standar dan statik seperti judul/ nama aplikasi, breadcrumb, ataupun pernyataan hak cipta dapat dicantumkan.
Gambar III – 3 adalah participant diagram yang menunjukkan screen, form, dan
screen compartment yang terlibat. Dan Gambar III – 4 adalah storyboard yang menunjukkan runutan ditampilkannya halaman berdasarkan skenario.
Keberadaan objek ‘Item’ pada Gambar III – 3 menunjukkan bahwa halaman daftar klien memiliki sebuah daftar berisikan lebih dari 1 klien (terkait dengan notasi ‘0…*’) dimana tiap klien memiliki atribut seperti nama, umur, email, dan alamat.
Gambar III-3 Participant Diagram Use Case Perbarui Data Kesehatan
Gambar III-4 Storyboard Use Case Perbarui Data Kesehatan
3.3 Model Perancangan
Salah satu use case akan diambil sebagai representasi pemodelan ini. Model ini melibatkan perancangan kelas dan file-file fisik untuk tahapan implementasi. Untuk model perancangan use case selengkapnya, dapat dirujuk pada Lampiran A – Dokumentasi Perancangan Lengkap APD.
3.3.1 Logical View Use Case Perbarui Data Kesehatan
Pada logical view, beberapa kelas lojik perlu didefinisikan. Sesuai dengan pendefinisian model UX sebelumnya, 3 buah halaman yang terlibat dalam use case ini akan direalisasikan dalam kelas berjenis client page. Untuk lebih jelasnya, dapat dilihat pada Tabel III – 6
Sebanyak 3 buah kelas form diperlukan untuk use case ini. ‘FormCariKlien’ (pada halaman daftar klien) digunakan untuk mencari klien yang ingin diperbarui data kesehatannya. ‘FormPilihKlien’, yang berupa menu pilihan di samping tiap data klien, digunakan untuk memilih klien. Dan ‘formTambahDataKes’ untuk menambahkan data kesehatan baru.
Dua buah kelas server page diperlukan untuk mengelola use case ini. Masing-masing
server page menghasilkan konten dinamis untuk satu atau beberapa halaman atau
form. Server page memiliki beberapa operasi atau algoritma utama untuk menjalankan use case ‘Perbarui Data Kesehatan’ dan memicu kelas entity untuk melakukan pemrosesan data pada database.
Tabel III-6 Identifikasi Logical View Use Case Perbarui Data Kesehatan No. Nama Elemen Lojik WAE Stereotype
1. halUtama Client Page
2. halDaftarKlien Client Page
3. formCariKlien HTML Form
4. formPilihKlien HTML Form
5. daftarKlien Server Page
6. halDataKes Client Page
7. formTambahDataKes HTML Form
3.3.2 Sequence Diagram Use Case Perbarui Data Kesehatan
Gambar III–5 menunjukkan diagram sekuensial use case ‘Perbarui Data Kesehatan’ yang dilengkapi dengan prosedur dan fungsi tiap kelas yang terlibat. Sebagian besar prosedur dan fungsi dimiliki oleh kedua kelas server page, ‘daftarKlien’ dan ‘kelolaDataKesehatan’ mengingat fungsi mereka sebagai pelaksana algoritma utama
use case. Kelas entity seperti ‘pengguna’, ‘genotipKlien’, dan ‘kesKlien’ adalah kelas yang berhubungan dengan pengambilan dan penyimpanan data dalam database. Kelas ini hanya memiliki fungsi ‘ambilData()’, ‘tambahData()’, dan ‘ubahData()’.
3.3.3 Diagram Kelas Perancangan Use Case Perbarui Data Kesehatan Pada Gambar III - 6, terdapat hubungan agregasi antara kelas ‘halDaftarKlien’ dengan ‘formCariKlien’ dan ‘formPilihKlien’ yang mengindikasikan form-form tersebut ditampilkan secara langsung beserta konten-konten lainnya pada halaman daftar klien (‘halDaftarKlien’). Hubungan komposisi ditunjukkan antara kelas ‘halDataKes’ dengan ‘formTambahDataKes’. Hubungan ini menunjukkan bahwa form yang ditampilkan akan menggantikan seluruh konten pada halaman tersebut. Sehingga fokus pengguna aplikasi akan beralih pada pengisian form tersebut.
3.3.4 Component View Use Case Perbarui Data Kesehatan
Pendefinisian component view didasarkan pada penggunaan teknologi ASP .NET. Aplikasi web akan memiliki suatu kerangka dasar yang disebut master page. Beberapa konten statis dapat diletakkan pada master page ini seperti judul, daftar menu, dan pernyataan hak cipta. Master page ini sesuai untuk mengimplementasikan
header, footer, dan menu utama.
ASP.NET akan menghasilkan dua buah file sekaligus untuk sebuah halaman web.
File.aspx berperan merealisasikan halaman berbasis HTML (kelas-kelas client page dan form), sedangkan File.cs akan merealisasikan kelas-kelas server page yang menyediakan pemrosesan di balik halaman web.
Tabel III-7 menunjukkan daftar component view use case ‘Perbarui Data Kesehatan’. Tabel III-7 Identifikasi Component View Use Case Perbarui Data Kesehatan
No. Nama Component View Stereotype
1. halUtama.aspx Static Page
2. daftarKlien.aspx Static Page
3. daftarKlien.cs Dynamic Page
4. kelolaDataKes.aspx Static Page
5. kelolaDataKes.cs Dynamic Page
6. kesKlien.cs Dynamic Page
7. pengguna.cs Dynamic Page
8. genotipKlien.cs Dynamic Page
9. ‘http://localhost/APD/daftarKlien.aspx’ Physical Root
Physical root yang ditunjukkan pada Tabel III-7 di atas, adalah URL yang dapat diketikkan pada web browser untuk menampilkan halaman-halaman use case ‘Perbarui Data Kesehatan’ yang dimulai dengan halaman daftar klien.
Gambar III - 7 menunjukkan pemetaan component view yang merealisasikan kelas-kelas logical view tertentu.
Gambar III-7 Diagram Realisasi Logical View Use Case Perbarui Data Kesehatan
3.4 Pemetaan Model UX dengan Component View
Tabel III - 8 menunjukkan pemetaan tiap model UX yang direalisasikan component
view tertentu: Pemetaan ini ditujukan untuk memeriksa apakah model UX yang telah didefinisikan sebelumnya telah direalisasikan dalam component view yang ada.
Pemetaan use case selengkapnya dapat dirujuk pada Lampiran A–Dokumentasi Perancangan Lengkap APD
Tabel III-8 Pemetaan Model UX dan Component View Use Case Perbarui Data Kesehatan No. Nama Model UX Nama Component View
1. Halaman Utama halUtama.aspx
2. Halaman Daftar Klien daftarKlien.aspx 3. Halaman Hasil Cari Klien daftarKlien.aspx
Tabel III-8 Pemetaan Model UX dan Component View Use Case … (lanjutan) No. Nama Model UX Nama Component View
4. Halaman Data Kesehatan Klien kelolaDataKes.aspx 5. Halaman Perbarui Data Kesehatan kelolaDataKes.aspx
3.5 Penentuan Jenis Genotip
Pada use case ‘Rekam Data Tubuh’, seorang klien memasukkan data tubuhnya dengan mengisi form dan menjawab beberapa pertanyaan yang ada. Kemudian, APD akan menentukan seseorang tersebut termasuk ke dalam suatu jenis Genotip tertentu.
Gambar III - 9 menunjukkan alur mekanisme penentuan jenis genotip untuk seorang klien pada APD.
Gambar III-8 Flowchart Penentuan Jenis Genotip pada APD
Mekanisme dimulai dengan kondisi seorang klien tidak mengetahui genotip apa yang mencerminkan dirinya dan diakhiri dengan terpilihnya salah satu jenis genotip yang paling dominan pada klien. Dalam mekanisme ini, terdapat 2 proses penting, yaitu proses penggunaan tabel inferensi dan proses pengukuran kekuatan genotip.
Perbedaan dari penggunaan ketiga jenis kalkulator genotip adalah pada hasil pemeriksaan tabel inferensi sifat genotip. Untuk kalkulator dasar, seorang klien akan menemukan 4 kemungkinan genotip yang dominan pada dirinya. Kalkulator menengah akan menghasilan 2 jenis genotip yang mungkin. Sedangkan kalkulator lanjut, menghasilkan tepat 1 jenis genotip yang paling dominan pada klien. Diperlukan mekanisme berikutnya bagi klien yang memilih kalkulator dasar atau menengah, yaitu proses pengukuran kekuatan genotip.
3.5.1 Tabel Inferensi Sifat Genotip
Tabel inferensi akan diimplementasikan ke dalam database. Tabel ini berperan menentukan kemungkinan genotip yang dominan pada tubuh klien. Untuk tiap jenis kalkulator genotip yang dipilih, hasil inferensi dari tabel akan berbeda-beda.
Tabel inferensi menggunakan beberapa data berikut untuk menentukan kemungkinan genotip yang dominan pada tubuh seorang klien:
1. Perbandingan antara panjang total kaki dengan panjang torso badan 2. Perbandingan antara panjang kaki atas dengan panjang kaki bawah 3. Perbandingan panjang antara jari telunjuk dengan jari manis 4. Jenis golongan darah (A, B, AB, atau O)
5. Jenis Rhesus darah (‘+’ atau ‘–‘)
6. Status Sekretor tubuh (‘sekretor’ atau ‘non-sekretor’)
Dari kemungkinan yang ada, akan muncul banyak kombinasi dari data-data tersebut. Untuk menyederhanakan representasi ke dalam sebuah tabel, sebuah kombinasi khusus karakter diperlukan untuk menyatakan nilai dari data nomor 1, 2, dan 3 di atas. Kemudian kombinasi khusus ini akan dicocokkan dengan nilai dari data nomor 4, 5, dan 6 untuk mendapatkan genotip kandidatnya. Berikut adalah algoritma yang digunakan untuk membentuk kombinasi karakter ini.
String kode;
kode = (pjgKaki =< pjgBadan) ? “a” : “b” + (kakiAtas >= kakiBawah) ? “a” : “b”;
if (telunjukManis == “beda”) then kode += “c”; else { if (telunjuk) then kode += “a”; else kode += “b”; } return kode;
Data perbandingan panjang total kaki – panjang badan dan perbandingan panjang kaki atas – kaki bawah dinyatakan dalam karakter ‘a’ (lebih panjang) atau ‘b’ (lebih pendek). Untuk data perbandingan jari telunjuk dengan jari manis, akan direpresentasikan dengan karakter ‘a’ (lebih panjang di kedua tangan), ‘b’ (lebih pendek di kedua tangan), atau ‘c’ (berbeda di kedua tangan).
Untuk lebih memperjelas, berikut adalah contoh definisi kombinasi karakter yang dihasilkan:
• Kombinasi : bac
Definisi : Badan lebih pendek daripada panjang kaki total, kaki atas lebih panjang daripada kaki bawah, dan perbandingan panjang jari telunjuk dan jari manis di kedua tangan tidak sama (lebih pendek di satu tangan dan lebih panjang di tangan lainnya).
Tabel III - 9 menunjukkan format tabel inferensi yang akan digunakan dalam APD. Tabel III-9 Tabel Inferensi Sifat Genotip
Gol.
Darah Rhesus Sekretor aaa aab aac aba abb abc baa bab bac bba bbb bbc
A + Sekretor 3 3 3 5 3 3 5 5 3 5 5,3 3 Non 3,4 4,3 3 5 3 3 5 5,4 3 5 5,3 5 - Sekretor 3,4 3 3 5 4,3 3 4 5 3 5 5,3 3 Non 4 4 3 4 4,3 3 4 4 4 5,4 4,3 5 AB + Sekretor 6 6 5 6,5 3 3 6,5 5 3 6,5 6,5 6,5 Non 4 6 5 6,5 3 3 6,5 5 4 6,5 6,5 6,5 - Sekretor 6,4 6,4 4 6,5 3 3 5 5 3 5 5 5 Non 4 4 4 6,5 4 4 5 4 4 5 5 5 B + Sekretor 6 6 2 6 6 6 6,2 6 2 6 6 6 Non 6 6 2 2 4,6 2 2 6 2 6,2 4,6 6,4 - Sekretor 6,4 6,4 4 2 4 4 6,4 4,6 4 2 4,6 4 Non 4 4 4 2 4 4 4 4 4 2 4,6 4 O + Sekretor 2 1 2 2 1 2 2 1 1 2 1 1 Non 2 4,1 2,4 2 1 2 2,4 1 2 2,4 1 1 - Sekretor 2 1 2,4 2 4 2 2 4,1 1 2,4 1 1 Non 2,4 4,1 4 2,4 4,1 4 2,4 4,1 2 4 1 4
Pada tabel inferensi, wilayah dengan warna menunjukkan genotip yang diidentifikasi paling dominan pada tubuh klien. Representasi genotip dinyatakan dalam angka:
1. Menyatakan Genotip Pemburu 2. Menyatakan Genotip Pengumpul 3. Menyatakan Genotip Guru 4. Menyatakan Genotip Penjelajah 5. Menyatakan Genotip Prajurit 6. Menyatakan Genotip Pengembara
Beberapa nilai pada kolom Tabel III - 9 tersebut dinyatakan dalam ‘x,y’. Nilai pertama (‘x’) ditujukan bagi klien yang berjenis kelamin perempuan, sedangkan nilai kedua (‘y’) ditunjukkan bagi klien laki-laki.
Berikut adalah algoritma yang digunakan untuk mekanisme inferensi sifat genotip:
String golDarah; //info golongan darah klien String rhesus; //info rhesus darah klien String sekretor; //info status sekretor klien
String kode; //kode karakter khusus tubuh klien String jnsKelamin; //info jenis kelamin klien
//string query untuk tabel Inferensi Sifat Genotip di database
String cmdString = "Select " + kode + " From InferensiSifatGenotip ";
//penambahan kondisi query, sesuai dengan diketahui atau tidaknya //golongan darah, rhesus, dan sekretor klien
if (golDarah != null) then {
cmdString += "Where golDarah = '" + golDarah + "' "; if (rhesus != null) then {
cmdString += "and rhesus = '" + rhesus + "' "; if (sekretor != null) then
cmdString += "and sekretor = '" + sekretor + "'"; }
}
//fungsi ExecuteQuery() akan mengeksekusi query dan mengembalikan //data berupa List of String
List<string> hasilAkhir; // menyimpan himpunan genotip akhir
//mekanisme normalisasi list for (i=0; i<count(kandidat); i++) {
//untuk kolom dengan format (x,y) if (kandidat[i].length > 1) then {
//pemeriksaan jenis kelamin
if (jnsKelamin == “perempuan”) then
//fungsi Substring(S, i, l) berfungsi untuk //mengambil sebagian karakter dari string S, yang //dimulai pada index ke i, dengan panjang l
kandidat[i] = Substring(kandidat[i], 0, 1); else
kandidat[i] = Substring(kandidat[i], 2, 1); }
//memastikan bahwa elemen yang ditambahkan pada list hasilAkhir //bersifat unik
if (not isMemberOf(hasilAkhir, kandidat[i])) then addList(hasilAkhir, kandidat[i]);
}
return hasilAkhir; //list berisi kode genotip kandidat klien
Melalui tahap inferensi, dapat dibuktikan bahwa klien yang menggunakan kalkulator dasar, hasil inferensinya akan berbeda dengan klien yang menggunakan kalkulator menengah atau lanjut. Dalam kalkulator dasar, klien tidak mengetahui golongan darahnya, rhesus, serta status sekretor.
Misalkan, untuk klien dengan kalkulator dasar, jika kombinasi khusus yang dihasilkan adalah ‘aab’, maka hasil akhir himpunan kandidat genotip, sesuai dengan algoritma yang telah dirancang, adalah {3, 4, 6, 1}. Klien yang bersangkutan akan memperoleh 4 kemungkinan genotip yang dominan pada tubuhnya. Untuk mendapatkan jawaban pasti mengenai genotip apa yang paling dominan, proses pengukuran kekuatan keempat genotip tersebut harus dilakukan.
3.5.2 Pengukuran Kekuatan Genotip
Proses pengukuran kekuatan genotip digunakan untuk mengidentifikasi jenis genotip yang paling kuat di antara himpunan hasil dari tabel inferensi melalui beberapa pertanyaan spesifik. Tiap-tiap pertanyaan akan memiliki skor tersendiri dan akan diakumulasikan untuk menghasilkan nilai kekuatan tiap genotip.
Format tabel database yang akan menyimpan pengukuran ini ditunjukkan pada Tabel III – 10.
Tabel III-10 Tabel Pengukuran Kekuatan Genotip
Pertanyaan akan menyatakan sebuah kondisi fisiologis yang harus dicocokkan dengan kondisi tubuh klien. Kolom ‘Genotip’ pada Tabel III - 10 menyimpan nomor genotip (dari 1 sampai 6) apa saja yang akan dipengaruhi kekuatannya oleh sebuah pertanyaan dalam bentuk himpunan (seperti ‘1,3,5’). Kemudian, skor dari pertanyaan akan ditambahkan pada nilai kekuatan genotip yang dipengaruhi jika kondisi cocok.
Pada contoh sebelumnya, dengan kombinasi ‘aab’, maka kandidat genotip yang mungkin dominan adalah Guru, Pemburu, Penjelajah, atau Pengembara. Nilai kekuatan dari tiap-tiap genotip kandidat ini akan dihitung bersama-sama saat klien menjawab pertanyaan. Setelah seluruh pertanyaan terjawab, nilai total kekuatan tiap genotip akan dibandingkan dan genotip dengan nilai tertinggi akan muncul dinyatakan sebagai genotip dominan.
Berikut adalah algoritma yang digunakan untuk pengukuran kekuatan genotip.:
String kandidat[] = (“Pemburu”, “Pengumpul”, “Guru”, “Penjelajah”, “Prajurit”, “Pengembara”,);
String pertanyaan[][]; //pertanyaan rumusan Dr. J. D’Adamo //pertanyaan[i][0]: kalimat pertanyaan //pertanyaan[i][1]: jawaban
//pertanyaan[i][2]: skor pertanyaan //pertanyaan[i][3]: himpunan id genotip
String jawaban[]; //list jawaban klien, klien harus //menjawab seluruh pertanyaan yang ada
String genotip; //info genotip klien
String kandidatGenotip[]; //daftar genotip kandidat klien
int nilai[6] = {0,0,0,0,0,0} //penyimpan nilai kekuatan tiap genotip
int idx; //menyimpan indeks untuk kekuatan[]
//melakukan perulangan untuk setiap pertanyaan for (i=0; i<count(pertanyaan); i++) {
//memeriksa, apakah pertanyaan tersebut diperhitungkan
//fungsi isBeririsan(list1, list2) akan memeriksa apakah list1 //memiliki satu atau beberapa elemen yang sama dengan list2 if (isBeririsan(kandidatGenotip, pertanyaan[i][3])) then {
if (pertanyaan[i][1] == jawaban[i]) then {
for (j=0; j<pertanyaan[i][3].length; j++) { //memastikan bahwa elemen adalah angka if (pertanyaan[i][3][j] != “,”) then {
//menentukan indeks untuk array nilai[] idx = toInt(pertanyaan[i][3][j])-1); //menambahkan skor kekuatan
nilai[idx] += toInt(pertanyaan[i][2]); } } } } }
//fungsi getIndex(a, e) mengembalikan nomor indeks elemen e dari //array a, sedangkan fungsi max(array) akan mengembalikan nilai //maksimum dari sebuah array
return kandidat[getIndex(nilai, max(nilai))];
3.6 Mekanisme Kalkulator Diet
Pada use case ‘Ukur Pola Diet’, klien memasukkan pola makan dan olahraga yang dijalani ke dalam APD untuk kemudian dinilai kesesuaiannya. Beberapa menu masukan disediakan bagi klien untuk memilih jenis makanan dan olahraga beserta porsinya. Mekanisme perhitungan APD didasarkan pada kesesuaian bahan makanan atau jenis olahraga (beserta porsinya) dengan pola diet ideal secara genotip.
Beberapa kategori unsur diet akan dipertimbangkan dalam APD: 1. Daging Merah
2. Unggas
3. Ikan dan Makanan Laut 4. Telur dan telur ikan 5. Produk Susu 6. Protein Nabati 7. Lemak dan Minyak
3.6.1 Penyimpanan Komponen Diet dalam Database
Untuk mekanisme ini, diperlukan sebuah skema tabel statis khusus. Akan terdapat tabel untuk setiap kategori sebagai penyimpan macam makanan atau olahraga yang termasuk ke dalam kategori tersebut. Gambar III-9 menunjukkan format tabel yang digunakan untuk setiap kategori.
Gambar III-9 Skema Tabel Penyimpan Komponen Diet
Akan terdapat sejumlah 14 tabel dengan format yang sama. Kolom ‘nama’ menyimpan nama dari macam makanan atau olahraga. Kolom ‘genotipAnjuran’ menyimpan himpunan nomor genotip yang dianjurkan untuk mengkonsumsi macam makanan atau untuk melakukan macam olahraga. Sedangkan kolom ‘genotipHindari’ menyimpan himpunan nomor genotip yang disarankan untuk menghindari atau membatasi diri dari macam makanan tersebut.
Tabel komponen diet menyimpan multivalue pada kolom ‘genotipAnjuran’ dan ‘genotipHindari’, dengan format berupa himpunan. Tabel III-11 menunjukkan contoh data untuk tabel ‘DagingMerah’.
Tabel III-11 Contoh Data Tabel 'DagingMerah' dengan Format Himpunan Multivalue Nama genotipAnjuran genotipHindari
… … … Daging Sapi 1, 3, 5 2, 4, 6 Daging Kambing 1, 4, 5, 6 2 … … … 8. Karbohidrat 9. Makanan Segar 10. Buah-buahan 11. Rempah-rempah 12. Minuman
13. Bahan-bahan pelengkap dan tambahan 14. Olahraga
Format ini ditujukan untuk memudahkan penampilan menu pilihan makanan dan olahraga pada halaman use case ‘Ukur Pola Diet’ dimana klien akan diberikan sejumlah menu drop-down untuk memilih jenis makanan sesuai dengan pola diet yang dijalani. Sebuah menu diberikan untuk tiap kategori unsur diet. Dengan format tabel yang digunakan, kode program hanya perlu mengambil seluruh data pada tabel ‘DagingMerah’, menyimpan ke dalam sebuah list (dengan tiap elemennya memiliki nilai ‘nama’, list genotip yang dianjurkan, dan list genotip yang dihindari) kemudian menampilkan semua nilai dari kolom ‘nama’ ke dalam menu drop-down.
Cara penyimpanan multivalue yang digunakan bukan merupakan cara ideal. Tabel III-12 menunjukkan contoh data tabel ‘DagingMerah’ dengan format normal.
Tabel III-12 Contoh Data Tabel 'DagingMerah' dengan Format Multivalue Ideal Nama genotipAnjuran genotipHindari
… … …
Daging Sapi 1 2
Daging Sapi 3 4
Daging Sapi 5 6
Daging Kambing 1 2
Daging Kambing 4 NULL
Daging Kambing 5 NULL
Daging Kambing 6 NULL
… … …
Dengan format ideal, kode program tidak dapat langsung menampilkan isi dari kolom ‘nama’ ke dalam menu drop-down. Kode program harus melakukan penyesuaian untuk menghilangkan nilai berulang pada kolom ini. Kode program juga harus menyesuaikan kolom lain pada tabel untuk mendapatkan list kode genotip anjuran dan
list kode genotip hindari, yang mana pada format sebelumnya kedua list ini dapat langsung diperoleh dalam bentuk string (contoh: ‘1,3,5’).
Secara keseluruhan, kode program akan membutuhkan 2 buah list untuk format penyimpanan multivalue yang ideal, yaitu sebuah list untuk menyimpan data yang baru saja diambil dari database dan sebuah list untuk menyimpan data yang telah disesuaikan dengan tiap elemen memiliki nama jenis makanan yang unik dan tidak berulang, list genotip anjuran, dan list genotip hindari. Dengan demikian, format penyimpanan menggunakan himpunan lebih efektif mengingat kode program dan jumlah list yang diperlukan akan lebih sedikit.
Untuk fungsi keberadaan list genotip anjuran dan list genotip hindari akan dijelaskan pada sub-bab 3.6.2.
3.6.2 Penilaian Pola Diet Klien
Setelah melakukan pengambilan data komponen diet, akan diperoleh sebuah list yang menyimpan seluruh data tabel. Setiap elemen list akan memiliki 3 macam data:
1. Nama jenis makanan atau olahraga dalam bentuk string.
2. List nomor genotip yang dianjurkan terhadap jenis makanan atau olahraga tersebut, dalam bentuk string.
3. List nomor genotip yang disarankan untuk menghindari jenis makanan tersebut, dalam bentuk string.
Akan dilakukan pemeriksaan terlebih dahulu apakah id atau nomor genotip klien termasuk ke dalam list genotip anjuran atau list genotip hindari. Sebagai contoh, apabila klien memilih ‘Daging Sapi’ untuk kategori daging merah, maka kode program akan memeriksa apakah genotip klien termasuk dalam himpunan ‘1,3,5’ atau ‘2,4,6’. Kemudian pemeriksaan kesesuaian porsi makanan dan olahraga akan dilakukan menggunakan nilai porsi ideal klien yang disimpan pada tabel ‘Porsi’ dalam database. Format tabel ini dapat dilihat pada skema database APD yang ditunjukkan pada Gambar III-10.
Penilaian kesesuaian pola diet dinyatakan dalam prosentase. Setiap kategori unsur diet diberikan nilai tersendiri untuk kemudian diakumulasikan dengan kategori lain. Untuk itu dibutuhkan beberapa aturan penilaian:
• Dalam satu kategori, jika genotip klien termasuk dalam himpunan genotip anjuran akan diberikan nilai 0.75, dan untuk porsi yang sesuai dengan tabel ‘Porsi’ akan diberikan nilai 0.25.
• Dalam satu kategori, jika genotip klien termasuk dalam himpunan genotip hindari akan diberikan nilai 0.
• Dalam satu kategori, jika genotip klien tidak terdapat dalam himpunan genotip anjuran ataupun hindari akan diberikan nilai 0.25.
• Nilai terendah yang mungkin diperoleh untuk tiap kategori adalah 0, sedangkan nilai tertinggi adalah 1.
Berikut adalah algoritma yang digunakan untuk penilaian pola diet.
int porsiIdeal[14]; //porsi ideal untuk ke-14 komponen diet string dietKlien[14][3]; //pola diet klien
//dietKlien[i][0] = nama makanan //dietKlien[i][1] = genotip anjuran //dietKlien[i][2] = genotip hindari int porsiKlien[14]; //nilai porsi diet klien
char idGenKlien; //nomor genotip klien
//penyimpanan nilai kekuatan untuk tiap komponen diet int nilai[14] = {0,0,0,0,0,0,0,0,0,0,0,0,0,0};
for (i=0; i<14; i++) {
//memeriksa apakah genotip klien termasuk dalam list anjuran if (isMemberOf(dietKlien[i][1], idGenKlien) then
nilai[i] += 0.75; else
nilai[i] += 0.25;
//memeriksa jika bukan olahraga dan genotip klien
//termasuk dalam list hindari, hal ini dikarenakan tidak //ada olahraga yang harus dihindari
if (i != 13) && (isMemberOf(dietKlien[i][2], idGenKlien) nilai[i] -= 0.25;
if (porsiKlien[i] == porsiIdeal[i]) nilai[i] += 0.25;
}
//fungsi sum(arrayOfInt) akan menghitung nilai akumulasi elemen array return sum(nilai)/14; //nilai kesesuaian pola diet
3.7 Perancangan Skema Database
Gambar III – 10 menunjukkan skema database pada APD. Tabel-tabel yang terdapat dalam daerah berlabel ‘static’ merupakan tabel data statis yang berisi data kadar makanan, olahraga, serta beberapa resep makanan yang sesuai untuk tiap genotip. APD akan merujuk tabel-tabel ini untuk menganalisa pola diet klien dan memberikan beberapa tips diet yang sesuai.
Gambar III-10 Skema Database APD
3.8 Realisasi Kebutuhan Non-Fungsional
APD memiliki 3 buah komponen kebutuhan non-fungsional1. Terdapat mekanisme keanggotaan yang cukup aman dalam membatasi aplikasi dari lingkungan luar.
2. Antarmuka yang bersifat konvensional, intuitif, dan mudah digunakan. 3. Pembangunan aplikasi di atas framework yang umum dan mudah digunakan. APD didesain untuk digunakan hanya oleh ahli diet dan klien. Seseorang akan menjadi klien setelah melakukan tatap muka perdana dan telah didaftarkan oleh ahli diet dalam APD. Sedangkan seorang ahli diet akan memiliki akun setelah didaftarkan oleh administrator APD melalui jalur back-end. Dengan mekanisme yang ada, diharapkan APD memiliki unsur keamanan yang cukup kuat untuk implementasi di jaringan berskala kecil (internal organisasi).
Untuk antar muka yang konvensional, desain yang umum digunakan pada mayoritas
website akan dijadikan patokan. Gambar III - 11 menunjukkan penataan halaman APD:
Gambar III-11 Layout Aplikasi Pelatihan Diet
Header digunakan untuk menempatkan judul atau nama dari APD, beberapa menu, serta breadcrumb untuk memberikan tanda nama halaman di mana seorang pengguna sedang berada. Bagian Menu menampilkan menu utama yang dapat dipilih pengguna.
Content adalah bagian dimana ahli diet dan klien melakukan aktivitas utamanya pada APD. Sedangkan Footer digunakan untuk menampilkan informasi pelengkap seperti pernyataan hak cipta dan tanda tangan dari pembuat aplikasi.
Untuk memenuhi kebutuhan non-fungsional ketiga, APD dibangun dengan Microsoft Visual Web Developer Express Edition 2008. Kakas ini dipilih karena menggunakan
framework .NET milik Microsoft yang cukup familiar dan banyak digunakan saat ini. Metode visual programming yang ada akan membantu tahap pengembangan aplikasi. Selain itu, kakas ini juga mudah untuk didapatkan karena sifatnya yang gratis.
3.9 Perbedaan HCP dengan APD
Secara keseluruhan APD dirancang berdasarkan Health Coaching Project (HCP) yang pernah dikembangkan sebelumnya. Terdapat beberapa persamaan dan perbedaan dalam segi fitur dari kedua aplikasi. HCP memiliki lebih sedikit fitur daripada APD mengingat fitur HCP sudah cukup untuk digunakan dalam lingkungan perusahaan di Belanda. Sedangkan APD, yang menggunakan sebuah konsep diet khusus, akan
memiliki fitur lebih untuk menunjukkan mekanisme diet yang dianut. Tabel III-13 menunjukkan perbandingan fitur antara kedua aplikasi.
Tabel III-13 Tabel Perbandingan Fitur HCP dan APD
Fitur Aplikasi Health Coaching Project Aplikasi Pelatihan Diet 1. Bahasa yang digunakan
2. Mengunakan konsep diet tertentu 3. Fitur registrasi klien.
4. Fitur kuesioner untuk
mengidentifikasi tingkah laku, pola hidup dan kebiasaan klien
5. Fitur rekam tubuh untuk mengidentifikasi jenis genotip klien.
6. Fitur menambahkan data kesehatan baru klien.
7. Memiliki fitur untuk memantau perkembangan data kesehatan klien.
8. Terdapat fitur untuk komunikasi personal.
9. Terdapat fitur pemberian tips diet (dengan berlangganan).
10. Terdapat fitur untuk mengukur dan menilai pola diet klien.
Belanda Tidak Ada Ada Ada Tidak Ada Ada Ada Ada Tidak Ada Tidak Ada Indonesia Ada Ada Tidak Ada Ada Ada Ada Ada Ada Ada
Pada hasil perbandingan, dapat diketahui bahwa fitur penyediaan kuesioner online untuk identifikasi tingkah laku, pola hidup, dan kebiasaan klien ditiadakan pada APD. Hal ini dikarenakan kebijakan perusahaan De Arbodienst yang tidak memperbolehkan penulis untuk membawa format dan isi kuesioner ke lingkungan luar perusahaan. Oleh karena itu, fitur perekaman data tubuh diimplementasikan sebagai pengganti dari fitur kuesioner online dengan harapan, setidaknya detil mengenai kondisi fisiologis tubuh klien dapat diketahui.
