Kebutuhan Pengguna Kebutuhan Basis Data

3.2.2.1. Kebutuhan Pengguna

Berdasarkan arsitektur pada gambar 3.1 untuk memenuhi kebutuhan pengguna dalam berinteraksi dengan sistem serta untuk mengetahui kebutuhan- kebutuhan apa saja yang berpengaruh pada sistem nantinya, maka perlu dijabarkan kebutuhan apa saja yang akan dibutuhkan oleh pengguna, antara lain: 1. Handphone GSM tidak tergantung merk yang mendukung Java MIDP 2.0 2. Penggantian bahasa guna kenyamanan penggunaan, dalam aplikasi ini bahasa yang akan disediakan yaitu bahasa Inggris dan bahasa Indonesia. 3. Menu untuk menulis pesan baru 4. Informasi untuk mengetahui perbandingan antara pesan yang dikompres dengan yang tidak dikompres. Informasi tersebut meliputi prosentase rasio kompresi dan jumlah karakter lebih yang dapat diketikkan jika pesan dikompres dibandingkan dengan pesan yang tidak dikompres. 5. Menu untuk mengambil no tujuan pengiriman dari kontak, biasanya tersimpan dalam memori handphone atau memori sim-card, agar pengguna tidak menghafalkan deretan angka no penerima. 6. Menu untuk menyimpan pesan yang telah terkirim dan pesan masuk. Pesan yang telah tersimpan nantinya dapat dihapus atau diubah maupun dikirim ulang atau dikirim kepada no penerima lain. 7. Fasilitas pada handphone penerima apabila terdapat SMS masuk ketika aplikasi belum running maka otomatis aplikasi akan running secara otomatis, sehingga pesan yang masuk tidak ditangani oleh aplikasi SMS bawaan handphone, karena aplikasi SMS bawaan handphone tidak akan bisa menampilkan isi pesan yang telah terkompresi.

3.2.2.2. Kebutuhan Basis Data

Dalam pemrograman J2ME hanya terdapat 2 metode yang bisa digunakan dalam pengiriman SMS yaitu secara TextMessage atau BinaryMessage. Pada TextMessage jumlah karakter maksimal yang bisa dikirimkan adalah 160 karakter dan pada BinaryMessage jumlah data maksimal yang dapat dikirimkan sebanyak 140 byte. Ada berbagai macam algoritma untuk mengkompres teks antara lain algoritma Huffman, algoritma Run-Length-Encoding RLE, algoritma Lempel- Ziv-Welch LZW. Dari beberapa algoritma tersebut yang cocok diterapkan pada aplikasi ini adalah algoritma huffman karena hasil dari kompresinya berupa data biner yang dapat dikirimkan melalui metode binary message, sedangkan algoritma kompresi lainnya hasil kompresinya tetap berupa teks namun teks yang telah dikodekan menjadi kamus, jika menggunakan algoritma ini maka jumlah karakter yang dikirimkan maksimal hanya 160 karakter dan tidak sesuai dengan tujuan dari dibuatnya aplikasi ini yaitu mengirimkan karakter lebih banyak dari batas yang telah ditentukan, sehingga dibuat tabel konversi berdasarkan algoritma huffman. Untuk memaksimalkan kinerja dari aplikasi ini, maka dibuatlah 2 tabel untuk menyimpan hasil konversi algoritma huffman, tabel pertama digunakan untuk konversi dari kata atau singkatan yang sering muncul menjadi deretan string biner. Singkatan-singkatan kata yang digunakan yaitu kata yang dipilih lebih dari 10 orang responden, sedangkan tabel yang kedua digunkan untuk mengkonversi kata atau singkatan yang tidak termasuk dalam tabel pertama dalam hal ini kata yang jarang digunakan, sehingga konversi dilakukan terhadap tiap-tiap karakter pembentuk kata tersebut. Selain 2 tabel kenversi, juga dibutuhkan tabel untuk menyimpan pengaturan konfigurasi bahasa, pesan masuk dan pesan keluar. Dari analisa keterangan di atas aplikasi ini nantinya akan membutuhkan 5 buah tabel untuk menyimpan data konfigurasi bahasa, data pesan masuk, data pesan keluar, data konversi singkatan dan data konversi karakter. Penjelasan tabel- tabel tersebut sebagai berikut: 1. Tabel Konfigurasi bahasa, berisi 1 buah field untuk menyimpan kode bahasa. 2. Tabel Pesan Masuk, berisi 4 buah field untuk menyimpan tanggal pesan masuk, no pengirim, isi pesan dan status pesan. Status pesan ini digunakan untuk mengetahui apakah pesan masuk sudah dibaca atau belum. 3. Tabel Pesan Keluar, berisi 4 buah field untuk menyimpan tanggal pesan keluar, no penerima, isi pesan, dan status pesan. Status pesan ini digunakan untuk mengetahui apakah pesan keluar sudan dibaca atau belum. 4. Tabel Konversi Singkatan Kata ke biner, berisi 2 buah field untuk menyimpan singkatan-singkatan kata umum yang sering dipakai bersarkan survei serta field yang berisi deretan bit hasil konversinya. 5. Tabel Konversi Huruf ke biner, berisi 2 buah field untuk menyimpan karakter- karakter serta field yang berisi deretan bit hasil konversinya. Gambar 3.2 mengambarkan nama-nama tabel dan field-field beserta tipenya: Gambar 3.2. Model Data Fisik Aplikasi Setelah dilakukan kuisioner dan hasilnya diprosesdikonversi di luar sistem dengan algoritma huffman terdapat 2 tabel dengan data-datanya yang akan disimpan, tabel pertama adalah hasil konversi singkatan ke biner, dan tabel ke dua akan digunakan jika kata yang akan dikonversi tidak ada pada tabel pertama, maka kata tersebut akan dikonversi karakter per karakter. Tabel 3.1. Hasil Konversi Kode Biner untuk Singkatan Yang Sering Dipakai No Kata Biner No Kata Biner 1 aq 11001 17 dr 00101 2 km 11111 18 mkn 00100 3 yg 11110 19 coz 00011 4 kt 11101 20 gpl 000000 5 sy 11010 21 knp 111001 6 lm 11000 22 syg 101011 7 jg 10110 23 untk 101010 8 in 10111 24 plg 010110 9 ap 10000 25 jgn 001101 10 mo 10001 26 dgn 000011 11 klo 01101 27 mlm 01111 12 qm 01110 28 hrs 01010 13 tp 01100 29 bsk 1110000 14 btw 011001 30 dmn 011000 15 lg 01000 31 utk 11100011 16 jk 00111 32 bls 010111 Untuk pengembangan aplikasi lebih lanjut, tidak menutup kemungkinan kata-kata yang sering dipakai akan bertambah dan deretan bit-bit yang telah ada pasti akan berubah sehingga pada aplikasi tidak dapat medekompres jika menerima pesan dari aplikasi beda versi, hal inilah yang menjadi kelemahan algoritma huffman. Untuk mengatasi kelemahan ini, rencananya ketika aplikasi akan mengirimkan SMS, pada deretan biner pertama ditambahkan 4 bit yang menandakan versi dari aplikasi pengirim. Pada aplikasi penerima, sebelum pesan didekompres maka akan diambil 4 bit pertama tersebut untuk mengetahui tabel versi berapa yang akan digunakan untuk mendekompres pesan. Berikut adalah hasil konversi karakter simbol tunggal ke deretan biner, tabel 3.2 akan digunakan apabila selama proses kompres atau dekompres tidak menemukan data yang cocok pada tabel 3.1: Tabel 3.2. Hasil Konversi Kode Biner Untuk Tiap Karakter No karakter Biner No karakter Biner 1 a 01101 39 N 1000110 2 b 000101 40 O 1000100 3 c 00000 41 P 10010110 4 d 001011 42 Q 1001100010000 5 e 1010 43 R 1000111 6 f 011001 44 S 1000011 7 g 010101 45 T 100111 8 h 01000 46 U 10010111 9 i 00001 47 V 1000101001 10 j 0110001001 48 W 1000101000 11 k 01100011 49 X 10011000101 12 l 1011 50 Y 10000100 13 m 010100 51 Z 1001100010001 14 n 00110 52 space 01001 15 o 00100 53 1100011 16 p 010110 54 1100110 17 q 01100010000 55 1100100 18 r 00111 56 , 1100001 19 s 00011 57 - 1100101 20 t 0111 58 . 1100000 21 u 010111 59 ? 1100010 22 v 00101001 60 E 1100111 23 w 00101000 61 0 1110000 24 x 011000101 62 1 1110001 25 y 000100 63 3 1110011 26 z 01100010001 64 4 1110100 27 A 1000000 65 5 1110101 28 B 10000101 66 6 1110110 29 C 1001101 67 7 1110111 30 D 10001011 68 8 1111000 31 F 10011001 69 9 1111001 32 G 10010101 70 11111010 33 H 1001000 71 11111011 34 I 1000001 71 1111011 35 J 100110001001 73 2 1110010 36 K 1001100011 74 : 1111100 37 L 1001001 75 1111010 38 M 10010100 76 SISA 1111110 + asci

3.2.3 Use Case Diagram