BAB III ANALISIS DAN PERANCANGAN

Transkripsi

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 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 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.: 1. Karakteristik darah (golongan, rhesus, dan status sekretor) III-1

2 III-2 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 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

3 III-3 untuk mengelola data pengguna aplikasi. Gambar III-1 menunjukkan skema implementasi APD. Gambar III-1 Skema Implementasi Aplikasi Pelatihan Diet 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 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.

4 III-4 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 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 APD UC 1 Registrasi Seorang ahli diet mendaftarkan seorang klien baru untuk program diet. APD UC 2. Rekam Data Tubuh Seorang klien harus memasukkan data tubuh untuk keperluan diet genotip. APD UC 3. Ukur Pola Diet Klien mengukur pola diet yang dijalani dan mengetahui kelebihan atau kekurangannya. APD UC 4. Beri Tips Diet APD memberi tips kepada klien yang berisi saran olahraga, pola makan, serta resep masakan yang sesuai. Realisasi Kebutuhan APD F 1 APD F 2 APD F 8 APD F 6 APD F 7

5 III-5 Tabel III 3 Deskripsi Use Case APD (lanjutan) ID Use Case Deskripsi 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 UC 6. Lihat Data Kesehatan Seorang ahli diet ataupun klien dapat memantau data kesehatan secara berkala dan melihat perkembangannya. APD UC 7. Komunikasi Personal Ahli diet dan klien saling berkomunikasi dengan mengirimkan dan menerima pesan pribadi melalui APD. APD UC 8. Ubah Profil Klien dapat mengubah profil dan konfigurasi personal yang tersimpan. Realisasi Kebutuhan APD F 5 APD F 3 APD F 4 APD F 9 APD F 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 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 post-kondisi diberikan di tiap use case. Pre-kondisi adalah syarat yang harus dipenuhi

6 III-6 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 use case APD, use case Perbarui Data Kesehatan.

7 III 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, , dan alamat.

8 III-8 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 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

9 III-9 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 8. keloladatakesehatan Server Page

10 III Sequence Diagram Use Case Perbarui Data Kesehatan Gambar III-5 Sequence Diagram use Case Perbarui Data Kesehatan

11 III-11 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() 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. Gambar III-6 Diagram Kelas Use Case Perbarui Data Kesehatan

12 III 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. 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 kelaskelas logical view tertentu.

13 III-13 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

14 III-14 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.

15 III 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;

16 III-16 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. Rhesus Sekretor aaa aab aac aba abb abc baa bab bac bba bbb bbc Darah A AB B O Sekretor ,3 3 Non 3,4 4, , ,3 5 Sekretor 3, , ,3 3 Non , ,4 4,3 5 Sekretor , , ,5 6,5 6,5 Non , , ,5 6,5 6,5 Sekretor 6,4 6,4 4 6, Non , Sekretor , Non , ,2 4,6 6,4 Sekretor 6,4 6, ,4 4, ,6 4 Non ,6 4 Sekretor Non 2 4,1 2, , ,4 1 1 Sekretor 2 1 2, ,1 1 2,4 1 1 Non 2,4 4,1 4 2,4 4,1 4 2,4 4,

17 III-17 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; String rhesus; String sekretor; String kode; String jnskelamin; //info golongan darah klien //info rhesus darah klien //info status sekretor klien //kode karakter khusus tubuh klien //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> kandidat = ExecuteQuery(cmdString);

18 III-18 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.

19 III 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

20 III-20 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.

21 III-21 Beberapa kategori unsur diet akan dipertimbangkan dalam APD: 1. Daging Merah 8. Karbohidrat 2. Unggas 9. Makanan Segar 3. Ikan dan Makanan Laut 10. Buah-buahan 4. Telur dan telur ikan 11. Rempah-rempah 5. Produk Susu 12. Minuman 6. Protein Nabati 13. Bahan-bahan pelengkap dan tambahan 7. Lemak dan Minyak 14. Olahraga 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

22 III-22 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.

23 III-23 Untuk fungsi keberadaan list genotip anjuran dan list genotip hindari akan dijelaskan pada sub-bab 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 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 Nilai terendah yang mungkin diperoleh untuk tiap kategori adalah 0, sedangkan nilai tertinggi adalah 1.

24 III-24 Berikut adalah algoritma yang digunakan untuk penilaian pola diet. int porsiideal[14]; string dietklien[14][3]; int porsiklien[14]; char idgenklien; //porsi ideal untuk ke-14 komponen diet //pola diet klien //dietklien[i][0] = nama makanan //dietklien[i][1] = genotip anjuran //dietklien[i][2] = genotip hindari //nilai porsi diet klien //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.

25 III-25 Gambar III-10 Skema Database APD 3.8 Realisasi Kebutuhan Non-Fungsional APD memiliki 3 buah komponen kebutuhan non-fungsional 1. 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).

26 III-26 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 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

27 III-27 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.