Aplikasi Kompresi SMS Berdasarkan Singkatan Kata Yang Sering Dipakai Berbasis Java Midlet.

SKRIPSI

Disusun oleh :

MUHAMAD FARID RAMADHAN

NPM. 0434010040

JURUSAN TEKNIK INFORMATIKA

FAKULTAS TEKNOLOGI INDUSTRI

UNIVERSITAS PEMBANGUNAN NASIONAL “VETERAN” JAWA TIMUR

SURABAYA

SKRIPSI

Diajukan Untuk Memenuhi Sebagai Persyaratan

Dalam Memperoleh Gelar Sarjana Komputer

Jurusan Teknik Informatika

Disusun oleh :

MUHAMAD FARID RAMADHAN

NPM. 0434010040

JURUSAN TEKNIK INFORMATIKA

FAKULTAS TEKNOLOGI INDUSTRI

UNIVERSITAS PEMBANGUNAN NASIONAL “VETERAN” JAWA TIMUR

SURABAYA

APLIKASI KOMPRESI SMS BERDASARKAN SINGKATAN

KATA YANG SERING DIPAKAI BERBASIS JAVA MIDLET

Disusun Oleh :

MUHAMAD FARID RAMADHAN

0434010040

Telah disetujui untuk mengikuti Ujian Negara Lisan Gelombang II Tahun Akademik 2007/2008

Pembimbing Utama Pembimbing Pendamping

Hj. Asti Dwi Irfianti, S.Kom, M.Kom Prisa Marga Kusumantara, S.Kom NPT. 273 020 640 213 NPT. 282 110 640 206

Mengetahui,

Ketua Jurusan Teknik Informatika Fakultas Teknologi Industri UPN ”Veteran” Jawa Timur

Ir. Purnomo Edi Sasongko, MP NIP. 030 194 662

APLIKASI KOMPRESI SMS BERDASARKAN SINGKATAN

KATA YANG SERING DIPAKAI BERBASIS JAVA MIDLET

Disusun Oleh :

MUHAMAD FARID RAMADHAN

NPM. 0434010040

Telah dipertahankan di hadapan dan diterima oleh Tim Penguji Skripsi Jurusan Teknik Informatika Fakultas Teknologi Industri

Universitas Pembangunan Nasional ”Veteran” Jawa Timur Pada Tanggal 14 Desember 2007

Pembimbing : Tim Penguji :

1. 1.

Hj. Asti Dwi Irfianti, S.Kom, M.Kom Hj. Asti Dwi Irfianti, S.Kom, M.Kom NPT. 273 020 640 213 NPT. 273 020 640 213

2. 2.

Prisa Marga Kusumantara, S.Kom Made Kamisutara, ST, M.Kom NPT. 282 110 640 206

3.

Fetty Tri Anggraeny, S.Kom NPT. 282 020 640 208

Mengetahui,

Dekan Fakultas Teknologi Industri

Universitas Pembangunan Nasional ”Veteran” Jawa Timur

Ir. Bambang Wahyudi, MS NIP. 030 180 480

FAKULTAS TEKNOLOGI INDUSTRI

KETERANGAN REVISI

Kami yang bertanda tangan di bawah ini menyatakan bahwa mahasiswa berikut: Nama : Muhamad Farid Ramadhan

NPM : 0434010040 Jurusan : Teknik Informatika

Telah mengerjakan revisi/ tidak ada revisi*) pra rencana (design)/ skripsi ujian lisan gelombang II, TA 2007/2008 dengan judul:

“APLIKASI KOMPRESI SMS BERDASARKAN SINGKATAN KATA YANG SERING DIPAKAI BERBASIS JAVA MIDLET”

Surabaya, 28 Desember 2007 Dosen Penguji yang memerintahkan revisi:

1) Hj. Asti Dwi Irfianti, S.Kom, M.Kom NPT. 273 020 640 123

2) Made Kamisutara, ST, M.Kom

3) Fetty Tri Anggraeny, S.Kom NPT. 282 020 640 208

Mengetahui,

Pembimbing Utama Pembimbing Pendamping

Hj. Asti Dwi Irfianti, S.Kom, M.Kom Prisa Marga Kusumantara, S.Kom NPT. 273 020 640 123 NPT. 282 110 640 206

{

}

{

}

Penyusun : Muhamad Farid Ramadhan

i

ABSTRAK

Saat ini informasi merupakan suatu kebutuhan pokok bagi seluruh lapisan

masyarakat, salah satu teknologi perangkat bergerak yang banyak digunakan untuk saling bertukar informasi adalah short message service (SMS). Namun tarif SMS yang diberlakukan beberapa operator seluler di Indonesia sangat mahal dan tidak rasional jika dibandingkan dengan total biaya produksinya. Selain mahal, SMS juga memiliki keterbatasan, yaitu informasi teks yang dapat dikirimkan maksimal hanya 160 karakter, jika kelebihan beberapa karakter atau bahkan kelebihan hanya satu karakter saja, maka biaya yang harus dibayarkan 2 kali lipat.

Aplikasi kompresi SMS dalam Skripsi ini merupakan sebagai salah satu solusi untuk menekan biaya SMS. Adapun metodologi yang digunakan adalah identifikasi kebutuhan sistem dengan use-case modelling dan analisa kebutuhan informasi melalui survei lapangan dan kuisioner sebagai bahan isi dari materi sistem. Implementasi dari desain sistem menggunakan teknologi berbasis java untuk melakukan kompres dan dekompres SMS berdasarkan singkatan kata umum yang sering dipakai dan diterapkan pada berbagai macam merk handphone.

Uji kelayakan aplikasi dilakukan dengan melakukan serangkaian skenario uji coba antara lain: uji coba proses install dan uninstall pada handphone, uji coba pengiriman dan penerimaan pesan terkompresi melalui jaringan GSM, uji coba manipulasi pesan masuk dan pesan keluar. Hasil uji coba menunjukkan bahwa aplikasi dapat diinstall dan uninstall pada berbagai macam merk handphone yang mendukukung java versi 2. Hasil kompresi dari aplikasi memungkinkan pengguna dapat mengirimkan karakter pesan hingga 21% lebih banyak dari batas maksimal dengan biaya satu kali pengiriman, tergantung operator seluler yang digunakan. Pesan masuk dan pesan keluar dapat diubah, dihapus maupun dikirim ulang. Selain itu, aplikasi ini juga memberikan sarana-sarana kemudahan bagi pengguna demi kenyamanan pemakaian aplikasi, antara lain: penyimpanan konfigurasi bahasa antara bahasa Inggris dan bahasa Indonesia serta penyimpanan pesan masuk dan pesan keluar, sehingga konfigurasi bahasa dan pesan-pesan tersimpan tidak hilang ketika aplikasi dihentikan maupun handphone dalam kondisi mati.

ii

KATA PENGANTAR

Syukur Alhamdulillaahi rabbil ‘alamin terucap ke hadirat Allah SWT atas segala limpahan Kekuatan-Nya sehingga dengan segala keterbatasan waktu, tenaga, pikiran dan keberuntungan yang dimiliki penyusun, akhirnya penyusun dapat menyelesaikan Skripsi yang berjudul “Aplikasi Kompresi SMS Berdasarkan

Singkatan Kata Yang Sering Dipakai Berbasis Java Midlet” tepat waktu.

Skripsi dengan beban 4 SKS ini disusun guna diajukan sebagai salah satu syarat untuk menyelesaikan program Strata Satu (S1) pada jurusan Teknik Informatika, Fakultas Teknologi Industri, UPN ”VETERAN” Jawa Timur.

Melalui Skripsi ini penyusun merasa mendapatkan kesempatan emas untuk memperdalam ilmu pengetahuan yang diperoleh selama di bangku perkuliahan, terutama berkenaan tentang penerapan teknologi perangkat bergerak. Namun, penyusun menyadari bahwa Skripsi ini masih jauh dari sempurna. Oleh karena itu penyusun sangat mengharapkan saran dan kritik dari para pembaca untuk pengembangan aplikasi lebih lanjut.

Surabaya, 6 Desember 2007

iii

UCAPAN TERIMA KASIH

Penyusun menyadari bahwasanya dalam menyelesaikan Skripsi ini telah mendapat banyak bantuan dan dukungan dari berbagai pihak, untuk itu pada kesempatan yang berharga ini, penyusun mengucapan terima kasih kepada:

1. Ayahanda dan Ibu tersayang di rumah yang senantiasa memberikan dukungan dan mendoakan penyusun supaya Skripsi ini segera terselesaikan.

2. Bapak Ir. Edi Purnomo Sasongko, MP selaku Ketua Jurusan Teknik Informatika. 3. Ibu Hj. Asti Dwi Irfianti, S.Kom, M.Kom selaku Dosen Pembimbing I yang

telah giat meluangkan banyak waktu untuk memberikan arahan, ilmu dan dorongan serta motivasi kepada penyusun untuk menyelesaikan Skripsi ini. 4. Bapak Prisa Marga Kusumantara, S.Kom selaku Dosen Pembimbing II yang

dengan sabar telah meluangkan banyak waktu, pikiran dan tenaga di antara kesibukan beban-beban kegiatan akademik untuk memberikan bimbingan dan kesempatan penyusun untuk berkreasi dalam proses pembuatan Skripsi ini. 5. Bapak Achmad Junaidi, S.Kom, Bapak Priza Pandunata, S.Kom, Bapak Made

Kamisutara, ST, M.Kom dan Ibu Fetty Tri Anggraeny, S.Kom selaku Penguji Skripsi yang telah banyak memberi masukan serta membuka wawasan baru. 6. My AIM3, Yani Ari Setiawati si penyemangat hidup yang kemana-mana selalu

setia melewati hari-hari bersama dan mendamaikan suasana hati penyusun. 7. Saudara-saudara penyusun tercinta, Mas Arvid sekeluarga dan Mas Vega yang

telah memberikan hiburan ringan ketika penyusun berada pada titik jenuh. 8. Teman-teman spesial satu angkatan yang telah membantu ulfa (minjemin buku

iv

DAFTAR ISI

ABSTRAK... i

KATA PENGANTAR... ii

UCAPAN TERIMA KASIH... iii

DAFTAR ISI... iv

DAFTAR GAMBAR... vii

DAFTAR TABEL... ix

BAB I PENDAHULUAN... 1

1.1. Latar Belakang... 1

1.2. Perumusan Masalah... 3

1.3. Batasan Masalah... 3

1.4. Tujuan dan Manfaat... 4

1.5. Metodologi Pembuatan Skripsi... 4

1.6. Sistematika Pembahasan... 5

BAB II TINJAUAN PUSTAKA ... 7

2.1. Short Message Service (SMS) ... 7

2.1.1. Karakteristik SMS... 8

2.1.2. Mekanisme Kerja SMS... 9

2.2. Perbandingan Macam-macam Tipe Algoritma Kompresi Teks... 11

2.2.1. Algoritma Huffman...,... 12

2.2.2. Algoritma Run-Length-Encoding (RLE)... 17

2.2.3. Algortima Lempel-Ziv-Welch (LZW)... 18

2.3. Java 2 Micro Edition (J2ME) ... 19

2.3.1. Siklus Hidup Midlet... 21

2.3.2. Connected Limited Device Configurasion (CLDC) ... 23

2.3.3. Mobile Information Device Profile (MIDP)... 23

2.3.4. Push Registry…... 24

v

2.4. Thread... 28

2.4.1. Single Thread... 28

2.4.2. Multi Thread……... 30

BAB III ANALISA DAN PERANCANGAN SISTEM... 31

3.1. Analisa... 31

3.2. Perancangan Sistem... 32

3.2.1. Deskripsi Umum Sistem... 32

3.2.2. Kebutuhan Sistem... 33

3.2.2.1. Kebutuhan Pengguna... 34

3.2.2.2. Kebutuhan Basis Data... 35

3.2.3. Use Case Diagram... 39

3.2.4. Activity Diagram... 40

3.2.5. Class Diagram... 42

3.2.6. Sequence Diagram... 43

3.2.7. Perancangan Proses Latar... 44

3.2.8. Perancangan Antarmuka... 45

BAB IV IMPLEMENTASI... 51

4.1. Lingkungan Implementasi... 51

4.2. Implementasi Basis Data... 52

4.3. Implementasi Proses Latar... 60

4.4. Implementasi Antarmuka... 64

4.4.1. Form Daftar Menu Utama... 64

4.4.2. Form Tulis Pesan... 65

4.4.3. Form Entry No Tujuan dan Info Kompresi... 65

4.4.4. Form Daftar Pesan Masuk... 66

4.4.5. Form Pengolahan Pesan Masuk... 66

4.4.6. Form Daftar Pesan Keluar... 67

4.4.7. Form Pengolahan Pesan Keluar... 68

vi

BAB V UJI COBA DAN EVALUASI... 69

5.1. Lingkungan Uji Coba…... 69

5.2. Skenario Uji Coba…... 70

5.3. Pelaksanaan Uji Coba…... 71

5.3.1. Uji Coba Install Aplikasi pada Handphone... 72

5.3.2. Uji Coba Uninstall Aplikasi... 74

5.3.3. Uji Coba Mengetik Pesan ... 75

5.3.4. Uji Coba Mengambil No Tujuan dari Phone Book... 76

5.3.5. Uji Coba Mengirim Pesan Jika Terdapat Pulsa Aktif... 76

5.3.6. Uji Coba Mengirim Pesan Jika Masa Aktif Pulsa Habis... 78

5.3.7. Uji Coba Menerima Pesan Jika Aplikasi Tidak Running.... 79

5.3.8. Uji Coba Membaca Pesan Masuk Dari Versi Lebih Kecil.. 79

5.3.9. Uji Coba Membaca Pesan Masuk Dari Versi Lebih Besar. 80 5.3.10. Uji Coba Membalas Pesan Masuk... 81

5.3.11. Uji Coba Mengirim Ulang Pesan Keluar... 82

5.3.12. Uji Coba Menghapus Pesan Masuk Dan Pesan Keluar... 83

5.3.13. Uji Coba Terhadap Menu Tips... 83

5.3.14. Uji Coba Penggantian Bahasa... 80

5.3.15. Uji Coba Terhadap Menu Bantuan... 82

5.3.16. Uji Coba Terhadap data dan Konfigurasi aplikasi... 82

5.3.17. Uji Coba Rasio Kompresi Dan Prosentase Peningkatan... 83

5.4. Evalusi... 83

BAB VI PENUTUP... 88

6.1. Kesimpulan... 88

6.2. Saran... 89

DAFTAR PUSTAKA... 90

vii

DAFTAR GAMBAR

Gambar 2.1. Mekanisme pengiriman SMS intra-operator... 10

Gambar 2.2. Mekanisme pengiriman SMS inter-operator... 11

Gambar 2.3. Pohon Huffman untuk karakter “ABACCDA” ... 14

Gambar 2.4. Proses Decoding dengan menggunakan pohon Huffman... 16

Gambar 2.5. Hasil Proses kompresi LZW String ”ABBABABAC”... 19

Gambar 2.6. Arsitektur J2ME... 21

Gambar 2.7. Siklus Hidup Midlet... 22

Gambar 2.8. Elemen-elemen Push Registry... 25

Gambar 2.9. Interface pada paket WMA... 26

Gambar 2.10. Syntak Interface Message... 26

Gambar 2.11. Syntak Interface MessageConnection... 27

Gambar 2.12. Syntak menciptakan thread pada Java... 29

Gambar 2.13. Perbedaan proses antara Single-Thread dan Multi-thread... 30

Gambar 3.1. Arsitektur Sistem Kompresi SMS... 31

Gambar 3.2. Model Data Fisik Aplikasi... 36

Gambar 3.3. Use Case Diagram Aplikasi Kompresi SMS... 39

Gambar 3.4. Activity Diagram Send SMS... 40

Gambar 3.5. Activity Diagram Receive SMS... 41

Gambar 3.6. Class Diagram Aplikasi ... 42

Gambar 3.7. Sequence Diagram Latar... 43

Gambar 3.8. Antarmuka Menu Utama... 45

Gambar 3.9. Antarmuka Tulis Pesan... 46

Gambar 3.10. Antarmuka No Tujuan dan Info Kompresi... 47

Gambar 3.11. Antarmuka Pesan Masuk... 48

Gambar 3.12. Antarmuka Pengolahan Pesan Masuk... 49

Gambar 3.13. Antarmuka Pesan Keluar... 49

Gambar 3.14. Antarmuka Pengolahan Pesan Keluar... 50

Gambar 3.15. Antarmuka Pengaturan Bahasa... 50

Gambar 4.1. Spesifikasi Handphond Nokia 7610... 51

Gambar 4.2. Script ImplementasiTabel Konfigurasi Bahasa... 53

Gambar 4.3. Script ImplementasiTabel Pesan Masuk... 54

Gambar 4.4. Script ImplementasiTabel Pesan Keluar... 56

Gambar 4.5. Script ImplementasiTabel Konversi Singkatan Kata Ke Biner... 58

Gambar 4.6. Script ImplementasiTabel Konversi Singkatan Huruf Ke Biner.... 59

Gambar 4.7. Pseudocode ImplementasiProses Latar Algoritma Kompres... 60

Gambar 4.8. Pseudocode ImplementasiProses Latar Algoritma Dekompres... 61

Gambar 4.9. Pseudocode ImplementasiProses Latar Algoritma Terima SMS... 61

Gambar 4.10. Pseudocode ImplementasiProses Latar Algoritma Kirim SMS... 62

Gambar 4.11. Pseudocode ImplementasiProses Latar Cek Jumlah Karakter... 63

Gambar 4.12. Pseudocode ImplementasiProses Latar Hitung Rasio Kompresi... 63

Gambar 4.13. Form Daftar Menu Utama... 64

Gambar 4.14. Form Tulis Pesan... 65

Gambar 4.15. Form Entry No tujuan dan Info Kompresi... 66

viii

Gambar 4.17. Form Pengolahan Pesan Masuk... 67

Gambar 4.18. Form Daftar Pesan Keluar... 67

Gambar 4.19. Form Pengolahan Pesan Keluar... 68

Gambar 4.20. Form Pengaturan Bahasa... 68

Gambar 5.1. Spesifikasi Nokia 6600... 69

Gambar 5.2. Spesifikasi Sony Ericsson K530i... 69

Gambar 5.3. Spesifikasi Motorolla V3i... 69

Gambar 5.4. Proses Installasi Bagian 1... 72

Gambar 5.5. Proses Installasi Bagian 2... 72

Gambar 5.6. Proses Installasi Bagian 3... 73

Gambar 5.7. Proses Installasi Bagian 4... 73

Gambar 5.8. Proses Uninstall Bagian 1... 74

Gambar 5.9. Proses Uninstall Bagian 2... 74

Gambar 5.10. Proses Uninstall Bagian 3... 75

Gambar 5.11. Mengetik Pesan... 76

Gambar 5.12. Mengambil Phone book... 76

Gambar 5.13. Mengirim Pesan Pulsa Ada Bagian 1... 77

Gambar 5.14. Mengirim Pesan Pulsa Ada Bagian 2... 77

Gambar 5.15. Mengirim Pesan Pulsa Habis Bagian 1... 78

Gambar 5.16. Mengirim Pesan Pulsa Habis Bagian 2... 78

Gambar 5.17. Menerima Pesan Saat Aplikasi Mati... 79

Gambar 5.18. Menerima Pesan Dari Versi Kecil... 80

Gambar 5.19. Menerima Pesan Dari Versi Besar... 80

Gambar 5.20. Reply Pesan Masuk Bagian 1... 81

Gambar 5.21. Reply Pesan Masuk Bagian 2... 82

Gambar 5.22. Resend Pesan Keluar Bagian 1... 82

Gambar 5.23. Resend Pesan Keluar Bagian 2... 83

Gambar 5.24. Menghapus Pesan... 83

Gambar 5.25. Menu Tips... 84

Gambar 5.26. Penggantian Bahasa Bagian 1... 85

Gambar 5.27. Penggantian Bahasa Bagian 2... 85

Gambar 5.28. Menu Bantuan... 86

ix

DAFTAR TABEL

Tabel 2.1. SMSC Operator Seluler di Indonesia... 9 Tabel 2.2. Kode Huffman untuk karakter “ABCD”... 15 Tabel 2.3. Tahapan Proses Kompresi LZW... 18 Tabel 3.1. Hasil Konversi Kode Biner Untuk Singkatan Yang Sering Dipakai... 37 Tabel 3.2. Hasil Konversi Kode Biner Untuk Tiap Karakter... 38 Tabel 5.1. Hasil Uji Coba Rasio Kompresi dan Prosentase Peningkatan... 87

1

BAB I

PENDAHULUAN

1.1.Latar Belakang

Handphone (HP) saat ini bukan lagi suatu media yang asing bagi masyarakat, selain digunakan untuk berkomunikasi suara, salah satu layanan HP yang digemari oleh masyarakat adalah Short Message Services (SMS). Namun Menurut Misdiyono (2007), Tarif Selular di Indonesia sangat mahal karena sudah menjadi perhitungan akuntansi standar, bahwa harga jual suatu produk didapat dari biaya produksi ditambah biaya-biaya lainnya serta keuntungan yang hendak dicapai. Lima tahun yang lalu, biaya yang dikeluarkan operator seluler untuk membangun satu buah jaringan wireless saja bisa mencapai 300 dolar AS dan tarif SMS yang dikenakan waktu itu sekitar Rp. 350–500, kini setelah lima tahun berlalu, tarif yang dibebankan ke pelanggan pun tak jauh berbeda padahal investasi yang dikeluarkan operator sudah merosot tajam. Biaya pembangunan satu buah jaringan wireless saat ini sudah kurang dari 100 dolar AS sedangkan biaya produksi SMS yang sebenarnya hanya Rp. 74 per SMS, jika dibandingkan dengan tarif SMS Rp. 250-300 yang diberlakukan operator, hal ini berarti terjadi peningkatan 300-400% dari biaya produksi, seharusnya sangat memungkinkan tarif SMS hanya 1/3 dari yang berlaku saat ini. Selain tarif SMS yang mahal, operator seluler juga membatasi jumlah karakter yang dapat dikirimkan maksimal hanya 160 karakter, apabila pelanggan mengirimkan SMS kelebihan hanya beberapa karakter saja dari batas yang telah ditentukan maka biaya yang dibayarkan pelanggan terhitung dua kali pengiriman.

Sepertinya sulit bagi masyarakat untuk menikmati tarif SMS murah karena operator seluler belum rela menurunkan tarif SMS disebabkan karena permintaan pasar terhadap SMS masih tinggi. Meskipun tarif SMS mahal dan jumlah karakter terbatas, namun terdapat kemungkinan untuk memaksimalkan fungsinya. Pada Skripsi ini penyusun melakukan penelitian dengan merancang sebuah aplikasi kompresi SMS yang ditujukan pada HP berbasis Java, karena pada HP jenis ini di dalamnya telah terdapat paket Java 2 Micro Edition (J2ME), yaitu beberapa fasilitas bawaan dari pabrik pembuat masing-masing HP, fasilitas-fasilitas tersebut bisa dimanfaatkan untuk meningkatkan jumlah karakter SMS dengan biaya tetap.

Dalam setiap pengiriman SMS, jumlah karakter maksimal yang dapat dikirimkan adalah 160 karakter. Secara umum metode yang akan digunakan oleh aplikasi yaitu mengkompres setiap singkatan SMS yang sering dipakai pengguna menjadi bit-bit yang lebih pendek dari bit asalnya, sehingga bit sisa dapat digunakan untuk menuliskan karakter lainnya. Singkatan-singkatan SMS tersebut diperoleh dengan melakukan kuisioner terhadap 50 orang responden yang terdiri dari kalangan mahasiswa dan masyarakat umum. Kuisioner ini bertujuan untuk mengetahui singkatan-singkatan apa saja yang sering dipakai responden. Jenis-jenis singkatan SMS yang sering dipakai responden dikelompokkan dan dikodekan menjadi bit-bit yang lebih pendek untuk dijadikan tabel acuan kompresi.

Aplikasi yang akan dibuat ini diharapkan dapat mempunyai nilai ekonomis karena pengguna dapat mengirimkan SMS lebih dari 160 karakter dengan biaya yang tetap. Meskipun penghematan yang didapatkan hanya beberapa puluh karakter, tetapi cukup memberi dampak positif penghematan biaya bagi pengguna yang memanfaatkan aplikasi ini sebagai kebutuhan sehari-hari.

1.2.Perumusan Masalah

Berdasarkan latar belakang yang telah diuraikan sebelumnya, terdapat beberapa permasalahan yang akan diangkat dalam Skripsi ini, antara lain:

1. Bagaimana cara merancang aplikasi kompresi SMS berorientasi objek yang dapat memenuhi semua kebutuhan pengguna.

2. Bagaimana cara mengkompres dan dekompres karakter atau singkatan SMS. 3. Bagaimana cara mengirimkan SMS terkompresi pada jaringan GSM dan cara

menerima SMS terkompresi jika aplikasi penerima tidak running.

4. Bagaimana cara menyimpan pesan masuk dan pesan keluar serta konfigurasi aplikasi yang telah diatur pengguna pada HP.

5. Bagaimana membuat keluaran antarmuka aplikasi yang tetap responsif saat berinteraksi dengan pengguna.

1.3.Batasan Masalah

Dari perumusan masalah di atas, batasan dalam Skripsi ini adalah: 1. Pesan yang akan diproses hanya pesan dengan format teks.

2. Aplikasi yang dibuat ter-install pada HP pengirim maupun HP penerima.

3. Aplikasi bersifat stand alone yaitu berjalan sebagai sebuah program biasa pada HP, bukan sebagai sebuah dedicated program.

4. Aplikasi yang dibuat tidak dapat memanfaatkan fasilitas yang tersedia pada aplikasi SMS bawaan masing-masing HP.

5. Konfigurasi yang bisa diatur oleh pengguna hanya pilihan bahasa.

6. Penggunaan aplikasi ini hanya ditujukan pada semua merk HP berbasis Java yang mendukung profil MIDP versi 2.0.

1.4.Tujuan dan Manfaat

Tujuan pembuatan Skripsi ini adalah merancang dan membuat aplikasi yang dapat mengkompres teks pada SMS untuk meningkatkan jumlah karakter yang dapat dikirimkan dalam setiap pengiriman melalui jaringan GSM dengan biaya yang tetap, sehingga diharapkan mampu menghemat biaya yang dikeluarkan.

1.5.Metodologi Pembuatan Skripsi

Pembuatan Skripsi terbagi menjadi beberapa tahapan sebagai berikut: 1. Survei Lapangan

Pada tahap ini dilakukan survei dengan memberikan kuisioner kepada 50 orang responden yang terdiri dari mahasiswa dan masyarakat umum. Tujuan dari diadakan survei ini untuk mengetahui singkatan-singkatan kata umum apa saja yang sering dipakai responden dalam berkirim SMS, singkatan-singkatan tersebut akan dijadikan tabel acuan dalam kompresi SMS.

2. Studi Literatur.

Pada tahap ini dilakukan pengumpulan dokumen-dokumen, referensi-referensi, buku-buku, sumber dari internet, atau sumber-sumber lain yang diperlukan untuk merancang dan mengimplementasikan aplikasi.

3. Analisa dan Perancangan Aplikasi

Dari hasil studi literatur dan hasil survei lapangan akan dibuat deskripsi umum sistem serta dilakukan analisa kebutuhan sistem, selain itu juga dilakukan perancangan awal aplikasi yang akan dibuat, sehingga akan dihasilkan disain antarmuka dan proses yang siap untuk diimplementasikan.

4. Pembuatan Aplikasi.

Pada tahap ini merupakan tahap yang paling banyak memerlukan waktu karena model dan rancangan aplikasi yang telah dibuat diimplementasikan dengan menggunakan teknologi J2ME.

5. Uji coba dan evaluasi aplikasi.

Pada tahap ini aplikasi yang telah dibuat ini akan dilakukan beberapa skenario uji coba dan dievaluasi untuk kelayakan pemakaian sistem.

6. Penyusunan Buku Skripsi

Pada tahap ini merupakan tahap terakhir dari pengerjaan Skripsi. Buku ini disusun sebagai laporan dari seluruh proses pengerjaan Skripsi. dari penyusunan buku ini diharapkan dapat memudahkan pembaca yang ingin menyempurnakan dan mengembangkan aplikasi lebih lanjut.

1.6.Sistematika Pembahasan

Sistematika pembahasan yang dibuat dalam Skripsi ini disusun dalam beberapa bab, yang dijelaskan sebagai berikut:

BAB I PENDAHULUAN

Bab ini berisi tentang deskripsi umum Skripsi yang meliputi latar belakang, perumusan masalah, batasan masalah, tujuan dan manfaat, serta metodologi dan sistematika pembahasan.

BAB II TINJAUAN PUSTAKA

Bab ini berisi mengenai konsep dan teori pembelajaran yang menjadi landasan pembuatan Skripsi antara lain: SMS, Perbandingan Kinerja Algoritma Kompresi Teks, J2ME, Thread.

BAB III ANALISA DAN PERANCANGAN SISTEM

Bab ini berisi tentang analisa dari sistem yang akan dibuat dan perancangan sistem yang meliputi antara lain: deskripsi umum sistem, kebutuhan sistem, pemodelan sistem berorientasi objek, perancangan proses latar dan perancangan antarmuka aplikasi.

BAB IV IMPLEMENTASI

Bab ini berisi hasil implementasi dari perancangan yang telah dibuat sebelumnya yang meliputi: implementasi basis data, implementasi proses latar dan implementasi form-form antarmuka aplikasi.

BAB V UJI COBA DAN EVALUASI

Bab ini berisi penjelasan lingkungan uji coba aplikasi, skenario uji coba, pelaksanaan uji coba dan evaluasi dari hasil uji coba yang telah dilakukan untuk kelayakan pemakaian aplikasi.

BAB VI PENUTUP

Bab ini berisi kesimpulan dan saran untuk pengembangan aplikasi lebih lanjut dalam upaya memperbaiki kelemahan pada aplikasi guna untuk mendapatkan hasil kinerja aplikasi yang lebih baik.

7

BAB II

TINJAUAN PUSTAKA

2.1. Short Message Service (SMS)

Menurut Satriyantono (2002), Short Message Service (SMS) saat ini telah menjadi suatu trend, bahkan gaya hidup baru tersendiri. SMS merupakan sebuah revolusi, di mana layanan yang tidak berbasis suara malah lebih meledak. SMS pada awalnya tidak terhitung sebagai layanan penting dalam jaringan Global

System for Mobile Communication (GSM) karena SMS dikembangkan terutama

sebagai alat pengirim informasi data konfigurasi dari handset GSM dan tidak lebih dari sekedar layanan tambahan dan bagian dari protokol jaringan.

Penambahan fungsi SMS sebagai alat pengirim pesan singkat dari pengguna satu ke pengguna lainnya sebenarnya bukan merupakan solusi dari hasil pemikiran serius. Namun demikian pada akhirnya SMS menjadi sukses secara tak terduga sebagai layanan messaging paling populer di dunia. Hal ini tentunya memberikan pendapatan ekstra bagi operator selular yang akan memperoleh bayaran untuk tiap kiriman SMS melalui jaringannya. Sebuah sukses yang tidak disengaja, yang bahkan melebihi fungsi asli sebuah mobile phone, sebagai perangkat komunikasi bergerak berbasis suara

Keberhasilan dan popularitas SMS antara lain disebabkan beberapa hal yaitu : harga per kiriman tetap atau konstan, kemanan dan kesopanan, tidak mengganggu penerima, handal.

Menurut Zakaria dan Widiadhi (2006), SMS adalah sebuah teknologi yang memungkinkan untuk menerima atau mengirimkan pesan antar telepon bergerak. Teknologi ini pertama kali diperkenalkan pada tahun 1992 di Eropa oleh European

telecommunication Standarts Institute (ETSI), pada awalnya menjadi suatu standart

untuk telepon wireless yang berbasis GSM. Namun teknologi lain seperti CDMA pun memasukkan SMS ini sebagai fitur standart mereka.

2.1.1. Karakteristik SMS

Sebagai namanya, SMS berarti layanan pesan pendek, maka besar data yang ditampung oleh SMS sangat terbatas. Yunianto (2006) mengemukakan bahwa untuk satu SMS yang dikirimkan, hanya dapat menampung paling banyak sebesar

140 byte. Bila diubah kedalam bentuk karakter, maka untuk satu SMS hanya dapat

berisi paling banyak 160 karakter untuk karakter latin, dan 70 Karakter untuk karakter non-latin seperti karakter Cina maupun Jepang.

Untuk HP yang mampu mengirim SMS lebih dari 160 karakter dalam sekali kirim pada dasarnya bukan berarti SMS memiliki batasan menjadi lebih dari 160 karakter, namun ketika HP mengirimkan SMS yang memiliki karakter lebih dari 160 karakter, HP tersebut akan memecah SMS menjadi bagian-bagian kecil sebesar 160 karakter, kemudian pada HP penerima bagian SMS yang telah dipotong tersebut digabungkan kembali menjadi satu SMS utuh.

Beberapa karakteristik SMS lainnya, yakni:

a. Pesan SMS dijamin sampai atau tidak sama sekali, selayaknya email, sehingga jika terjadi kegagalan sistem, timeout, atau hal lain yang menyebabkan pesan

SMS tidak diterima, akan diberikan laporan (report) oleh Short Message

Service Center (SMSC) yang menyatakan bahwa pesan SMS gagal diterima.

b. Berbeda dengan fungsi pemanggilan, sekalipun saat mengirimkan SMS pada HP penerima yang sedang tidak aktif, bukan berarti pengiriman SMS akan gagal. Namun SMS akan masuk ke antrian terlebih dahulu selama belum

timeout, SMS akan segera dikirimkan jika HP penerima sudah aktif.

c. Lebar data yang digunakan rendah.

d. SMS yang dikirimkan tidak dapat ditolak oleh HP penerima, terkecuali jika pada HP penerima memiliki aplikasi penolak SMS masuk.

2.1.2. Mekanisme Kerja SMS

Ketika SMS dikirimkan ke suatu nomor tertentu, Yunianto (2006) mengemukakan bahwa SMS yang dikirimkan tersebut tidak langsung dikirimkan ke nomor tersebut, namun akan masuk terlebih dahulu ke SMSC operator telepon yang digunakan HP pengirim. SMSC digunakan untuk menjembatani atau menghubungkan antara HP pengirim dan HP penerima. Setelah pesan sampai pada SMSC, kemudian akan diteruskan ke handphone penerima. Begitu juga sebaliknya. SMSC dapat juga diartikan sebagai perangkat lunak yang terletak di jaringan operator dan mengatur proses-proses, seperti mengatur antrian pesan. Berikut ini adalah daftar alamat SMSC pada beberapa operator GSM di Indonesia:

Tabel 2.1. SMSC Operator Selular di Indonesia O p e ra to r G S M N o m o r S M S C

S a te lin d o 6 2 8 1 6 1 2 4 E x e lc o m in d o 6 2 8 1 8 4 4 5 0 0 9

T e lk o m s e l 6 2 8 1 1 0 0 0 0 0 IM 3 6 2 8 5 5 0 0 0 0 0 0

Secara umum, mekanisme kerja pengiriman SMS dibagi menjadi 2, yaitu:

1. Pengiriman SMS dalam satu operator atau sering disebut dengan intra-operator SMS. Gambar 2.1 menjelaskan SMS yang dikirimkan oleh nomor pengirim akan terlebih dulu dimasukkan ke dalam SMSC operator nomor pengirim, kemudian SMSC tersebut akan mengirimkan ke nomor yang dituju secara langsung. Nomor penerima kemudian akan mengirimkan sebuah delivery

report ke SMSC yang menyatakan bahwa SMS telah diterima. SMSC

kemudian meneruskan delivery report tersebut ke nomor pengirim SMS, disertai status report dari proses pengiriman SMS tersebut.

Gambar 2.1. Mekanisme pengiriman SMS intra-operator

2. Pada mekanisme ini, SMS yang dikirimkan akan melalui dua buah SMSC. Gambar 2.2 menjelaskan selain masuk ke SMSC operator pengirim, SMS yang dikirimkan akan diteruskan oleh SMSC operator pengirim ke SMSC operator penerima SMS, kemudian baru diteruskan ke nomor tujuan. Delivery report

yang dihasilkan pun akan melalui jalur tersebut, agar dapat sampai ke nomor pengirim SMS. Dalam mekanisme ini, terlihat ada sebuah komunikasi tidak langsung antara dua operator berbeda. Komunikasi tersebut dapat berjalan, setelah terjadi sebuah kesepakatan kerjasama antar operator tesebut. Tidak adanya sebuah kesepakatan kerjasama antar operator, dapat menyebabkan SMS yang dikirimkan ke nomor tujuan dengan operator berbeda, tidak sampai pada nomor tujuan tersebut.

Gambar 2.2. Mekanisme pengiriman SMS inter-operator

2.2. Perbandingan Macam-macam Tipe Algoritma Kompresi Teks

Menurut Linawati (2004), kompresi ialah proses pengubahan sekumpulan data menjadi suatu bentuk kode untuk menghemat kebutuhan tempat penyimpanan dan waktu untuk transmisi data. Terdapat beberapa tipe algoritma kompresi teks antara lain: Huffman, Run-Length-Encoding (RLE) dan Lempel-Ziv-Welch (LZW).

Berdasarkan tipe peta kode yang digunakan untuk mengubah pesan awal menjadi sekumpulan codeword, metode kompresi teks terbagi menjadi dua kelompok yaitu :

a. Metode Statik, yaitu menggunakan peta kode yang selalu sama. Metode ini membutuhkan dua tahap fase, fase pertama untuk menghitung kemunculan tiap simbol/karakter dan menentukan peta kodenya, dan pada fase kedua untuk mengubah pesan menjadi kumpulan kode yang akan ditransmisikan. Contoh: Algoritma Huffman.

b. Metode dinamik (adaptif), yaitu menggunakan peta kode yang dapat berubah dari waktu ke waktu. Metode ini disebut adaptif karena peta kode mampu beradaptasi terhadap perubahan karakteristik isi file selama proses kompresi berlangsung. Contoh: Algoritma LZW dan RLE.

Berdasarkan teknik pengkodean/pengubahan pesan awal atau simbol menjadi sekumpulan codeword, metode kompresi teks dapat dibagi menjadi dua kategori, yaitu:

a. Metode Symbolwise : menghitung peluang kemunculan dari tiap simbol dalam pesan masukkan, lalu mengkodekan satu simbol dalam satu waktu, di mana simbol yang lebih sering muncul diberi kode lebih pendek dibandingkan simbol yang lebih jarang muncul. Contoh: Algoritma huffman.

b. Metode Dictionary : menggantikan karakter/fragmen dalam pesan masukkan dengan indeks lokasi dari karakter/fragmen tersebut dalam sebuah kamus. Contoh: Algoritma LZW dan RLE.

2.2.1. Algoritma Huffman

Algoritma Huffman, yang dibuat oleh Mahasiswa MIT bernama David Huffman pada tahun 1952, merupakan salah satu metode paling lama dan paling terkenal dalam kompresi teks, Rinaldi (2003). Algortima huffman menggunakan prinsip pengkodean yang mirip dengan kode morse, yaitu tiap karakter dikodekan hanya dengan rangkaian beberapa bit, di mana karakter yang sering muncul dikodekan dengan rangkaian bit yang pendek dan karakter yang jarang muncul dikodekan dengan serangkaian bit yang lebih panjang.

Kode Huffman pada dasarnya merupakan kode prefik. Kode prefik adalah himpunan yang berisi sekumpulan kode biner, di mana pada kode prefik ini tidak ada kode biner yang menjadi awal bagi kode biner yang lain.

Kode prefik biasanya direpresentasikan sebagai pohon biner yang diberikan nilai atau label. Untuk cabang kiri pada pohon biner diberi label 0, sedangkan pada cabang kanan pohon biner diberi label 1. Rangkaian bit yang terbentuk pada setiap lintasan dari akar ke daun merupakan kode prefik untuk karakter yang berpadanan. Pohon biner ini biasa disebut pohon huffman.

Langkah-langkah pembentukan pohon huffman adalah sebagai berikut: 1. Baca semua karakter di dalam teks untuk menghitung frekuensi kemunculan

setiap karakter, setiap karakter penyusun teks dinyatakan sebagai pohon bersimpul tunggal. Setiap simpul ditandai dengan frekuensi kemunculan karakter tersebut.

2. Gabungkan dua buah pohon huffman yang mempunyai frekuensi terkecil pada sebuah akar. Setelah digabungkan akar tersebut akan mempunyai frekuensi yang merupakan jumlah dari frekuensi dari dua buah pohon penyusunnya. 3. Ulangi langkah ke dua sampai hanya tersisa satu buah pohon huffman, agar

pemilihan dua buah pohon yang akan digabungkan berlangsung cepat, maka semua yang ada selalu terurut menaik berdasarkan frekuensi.

Sebagai contoh, dalam kode ASCII string 7 huruf “ABACCDA” membutuhkan representasi 7 x 8 bit = 56 bit (7 byte). Dengan rincian sebagai berikut:

A = 01000001 C = 01000011 B = 01000010 D = 01000100 A = 01000001 A = 01000001 C = 01000011

Pada string di atas, frekuensi kemunculan A = 3, B = 1, C = 2, dan D =1

Encoding adalah cara menyusun string biner dari teks yang ada. Proses

encoding untuk satu karakter dimulai dengan membentuk satu buah pohon huffman

terlebih dahulu. Setelah itu, kode untuk satu karakter dibuat dengan menyusun nama string biner yang dibaca dari akar sampai ke daun pohon huffman. Langkah-langkah encoding suatu string biner adalah sebagai berikut:

1. Tentukan karakter yang akan di-encoding.

2. Mulai dari akar, baca setiap bit yang ada pada cabang yang bersesuaian sampai ketemu daun di mana karakter itu berada.

3. Ulangi langkah ke dua sampai seluruh karakter di-encoding.

Sebagai contoh dapat dilihat tabel di bawah ini, yang merupakan hasil encoding untuk pohon huffman pada gambar 2.3.

Tabel 2.2. Kode Huffman untuk karakter “ABCD”

Decoding merupakan kebalikan dari encoding. Decoding berarti menyusun

kembali data dari string biner menjadi sebuah karakter kembali. Decoding dapat dilakukan dengan dua cara, yang pertama dengan menggunakan pohon huffman dan yang kedua menggunakan tabel kode huffman. Langkah-langkah

men-decoding suatu string biner dengan menggunakan pohon huffman adalah:

1. Baca sebuah bit dari string biner mulai dari akar

2. Untuk setiap bit pada langkah satu, lakukan tranveral pada cabang yang bersesuaian.

3. lakukan langkah 1 dan 2 sampai bertemu daun. Kodekan rangakaian bit yang telah di baca dengan karakter di daun.

4. Ulangi dari langkah 1 sampai semua bit di dalam string habis.

Sebagai contoh, bagaimana men-decoding string biner yang bernilai “111” Setelah ditelusuri dari akar, maka akan ditemukan bahwa string yang mempunyai kode huffman “111” adalah karakter D.

Gambar 2.4. Proses Decoding dengan menggunakan pohon huffman

Cara yang kedua adalah menggunakan tabel kode huffman, sebagai contoh digunakan kode huffman pada tabel 2.2 untuk merepresentasikan string

“ABACCDA”. Dengan menggunakan tabel 2.2 tersebut akan direpresentasikan menjadi rangkaian bit : 0 110 0 10 10 1110. Jadi jumlah yang dibutuhkan hanya 13 bit. Dari Tabel 2.2 tampak bahwa kode untuk sebuah simbol/karakter tidak boleh menjadi awalan dari kode simbol yang lain guna menghindari ambiguitas dalam

proses dekompresi atau decoding. Karena tiap-tiap kode huffman yang dihasilkan unik, maka proses decoding dapat dilakukan dengan mudah. Contoh: saat membaca kode bit pertama dalam rangkaian bit “011001010110”, yaitu bit ”0” merupakan pemetaan dari simbol “A”. Kemudian dibaca kode bit selanjutnya, sehingga menjadi “11”. Tidak ada juga kode huffman “11” lalu baca lagi kode bit berikutnya, sehingga menjadi “110” adalah pemetaan dari simbol “B”.

2.2.2. Algorima Run-Length-Encoding (RLE)

Kompresi data teks dilakukan jika ada beberapa huruf yang sama yang ditampilkan berturut-turut.

Contoh: Data : ABCCCCCCCCDEFGGGG = 17 Karakter RLE tipe 1 (min. 4 huruf sama) : ABC!8DEFG!4 = 14 Karakter

RLE ada yang menggunakan suatu karakter yang tidak digunakan dalam teks tersebut, seperti misalnya ‘!’ untuk menandai. Kelemahan RLE jika ada karakter angka, membedakan mana tanda mulai dan akhir menjadi rancu.

Contoh: Data : ABCCCCCCCCDEFGGGG = 14 Karakter RLE tipe 2 : -2AB8C-3DEF4G = 12 Karakter Contoh: Data : AB12CCCCDEEEF = 13 Karakter RLE tipe 2 : -4AB124CD3EF = 12 Karakter

RLE ada yang menggunakan flag bilangan negatif untuk menandai batas sebanyak jumlah karakter tersebut. Berguna untuk data yang memiliki kesamaan, misal teks yang memiliki banyak kesamaan pola. Kondisi terbaik untuk RLE tipe 2 adalah ketika terdapat 127 karakter yang sama sehingga akan dikompres menjadi 2

byte saja. Dan kondisi terburuk untuk RLE tipe 2 adalah ketika terdapat 127 karakter yang bebeda semua, maka terdapat 1 byte tambahan sebagai tanda jumlah karakter yang tidak sama tersebut.

2.2.3. Algoritma Lempel-Ziv-Welch (LZW)

Menurut Linawati (2007), Algoritma LZW dikembangkan dari metode kompresi yang dibuat oleh Ziv dan Lempel pada tahun 1977. Algoritma ini melakukan kompresi dengan menggunakan dictionary, di mana fragmen-fragmen teks digantikan dengan indeks yang diperoleh dari sebuah “kamus”. Pendekatan ini bersifat adaptif dan efektif kaena banyak karakter dapat dikodekan dengan mengacu pada string yang telah muncul sebelumnya dalam teks. Prinsip kompresi tercapai dalam bentuk pointer dapat disimpan dalam jumlah bit yang lebih sedikit dibandingkan string aslinya.

Sebagai contoh, string “ABBABABAC” akan dikompresi dengan LZW. Isi

dictionary pada awal proses diset dengan tiga karakter dasar yang ada: “A”, “B”,

“C”. Tahapan proses kompresi ditunjukkan pada tabel 2.3.

Tabel 2.3. Tahapan Proses Kompresi LZW

Kolom posisi menyatakan posisi sekarang dari stream karakter dan kolom karakter

menyatakan string baru yang sudah ditambahkan ke dalam dictionary dan nomor indeks untuk string tersebut ditulis dalam kurung siku. Kolom output menyatakan kode output yang dihasilkan oleh langkah kompresi. Hasil proses kompresi ditunjukkan pada gambar 2.5

Gambar 2.5. Hasil Proses Kompresi LZW String ”ABBABABAC”

2.3. Java 2 Micro Edition (J2ME)

Menurut Raharjo dan Heryanto (2007), Java adalah bahasa pemrograman yang disusun oleh James Gosling dan dibantu oleh rekan-rekannya seperti Patrick Naughton, Chris Warth, Ed Frank, dan Mike Sheridan pada tahun 1991 di suatu perusahaan perangkat lunak bernama Sun Microsystems. Bahasa pemrograman ini mula-mula diinisialisasi dengan nama “Oak”, namun pada tahun 1995 diganti namanya menjadi “Java”.

Alasan utama pembentukan bahasa Java adalah untuk membuat aplikasi-aplikasi yang dapat diletakkan di berbagai macam perangkat elektronik, seperti

microwave oven dan remote control, sehingga Java harus bersifat portable atau

yang sering disebut dengan platform-independent (tidak tergantung pada platform). Itulah yang menyebabkan dalam dunia pemrograman java, dikenal adanya istilah

‘write once, run everywhere’, yang berarti kode program hanya ditulis sekali,

perubahan kode program. Sun Microsystems telah mendefinisikan tiga buah edisi dari Java 2, yaitu sebagai berikut:

1. Java 2 Standard Edition (J2SE), yang digunakan untuk mengembangkan

aplikasi-aplikasi desktop dan applet (aplikasi Java yang dapat dijalankan di dalam browser web).

2. Java 2 Enterprise Edition (J2EE), Merupakan superset dari J2SE yang

memperbolehkan untuk mengembangkan aplikasi-aplikasi berskala besar, yaitu dengan pembuatan aplikasi-aplikasi di sisi server dengan mengunakan EJBs

(Enterprise JavaBeans), aplikasi web dengan menggunakan Servlet dan JSP

(Java Server Pages) dan teknologi lainnya seperti CORBRA (Common Object

Request Broker Architecture) dan XML (Extensible Markup Language).

3. Java 2 Micro Edition (J2ME), merupakan subset dari J2SE yang digunakan

untuk menangani pemrograman di dalam perangkat-perangkat kecil, yang tidak memungkinkan untuk mendukung implementasi dari J2SE secara penuh.

J2ME merupakan sebuah kombinasi yang terbentuk antara sekumpulan

interface Java yang sering disebut dengan Java API (Application Programming

Interface) dengan JVM (Java Virtual Machine) yang didesain khusus untuk

perangkat dengan ruang memori terbatas. Kombinasi tersebut kemudian digunakan untuk melakukan pembuatan aplikasi-aplikasi yang dapat berjalan pada mobile device.

Masing-masing dari perusahaan perangkat telah menyediakan JVM dan sekumpulan API yang diperlukan, sehingga tidak perlu dilakukan installasi JVM dan Java API ke dalam perangkat sehingga programmer hanya berkonsentrasi

dalam pengembangan aplikasinya dan memasukkannya kedalam perangkat tersebut.

J2ME sendiri pada dasarnya terdiri dari tiga buah bagian, yaitu: konfigurasi, profil, dan paket-paket opsional, seperti yang ditunjukkan pada gambar 2.6:

Gambar 2.6. Arsitektur J2ME

2.3.1. Siklus Hidup Aplikasi J2ME

Application Management Software (AMS) merupakan lingkungan tempat

sebuah Midlet dapat di-install, dijalankan, dihentikan maupun di-uninstall. AMS akan membuat instance baru dari Midlet dan dapat mengontrol keadaannya, yaitu dengan cara menjalankan (start), mengistirahatkan (pause) maupun menghentikannya (destroy) secara langsung oleh dirinya sendiri.

Terdapat tiga buah method yang harus diimplementasikan oleh setiap Midlet. Dengan kata lain, setiap Midlet yang dibuat harus memilik ketiga buah

destroyApp(). Setiap Midlet dapat berada dalam salah satu keadaan (state) berikut,: Pause, Active, maupun Destroyed. Gambar Siklus berikut ini akan mengilustrasikan ketiga buah keadaan tersebut dan pada saat kapan Midlet akan berada dalam keadaan tertentu.

Gambar 2.7. Siklus Hidup Midlet

Tampak pada gambar 2.7 bahwa pada saat pembuatan Midlet baru, mula-mula Midlet akan berada dalam keadaan Paused. Apabila proses pembuatan Midlet gagal atau mengakibatkan kesalahan, maka Midlet akan langsung berada pada keadaan Destroyed. Namun apabila proses pembuatan Midlet berjalan dengan baik, maka setelah Midlet dijalankan, maka AMS secara otomatis akan mengeksekusi

method startApp() dan hal ini akan mengubah MIDlet untuk berada dalam

keadaan Active dan dapat diubah kembali menjadi keadaan Paused melalui pemanggilan method pauseApp() atau diubah menjadi keadaan Destroyed melalui pemanggilan method destroyApp(). Sebagai contoh, pada saat Midlet akan mengalami perubahan keadaan, yaitu dari Active menjadi Destroyed.

2.3.2. Connected Limited Device Configurasion (CLDC)

Konfigurasi merupakan bagian yang berisi JVM dan beberapa library

standar yang digunakan untuk input, output, security pada pada mobile devices

yang support dengan java.

CLDC adalah sebuah konfigurasi yang terdapat di dalam J2ME untuk alat-alat yang memiliki keterbatasan ruang memori atau RAM (kurang dari 512 KB) dan pada umumnya dioperasikan dengan menggunakan baterai, serta memiliki

bandwith kecil, contoh alat-alat kecil, seperti telepon selular, PDA dan pager.

2.3.3. Mobile Information Device Profile (MIDP)

Profil merupakan bagian perluasan dari konfigurasi. Artinya, selain sekumpulan kelas yang terdapat pada konfigurasi, terdapat juga beberapa kelas-kelas spesifik yang didefinisikan lagi dalam profil. Dengan kata lain, profil akan membantu secara fungsional yaitu dengan menyediakan kelas-kelas yang tidak terdapat pada level konfigurasi

Adapun profil yang sangat popular penggunaannya adalan profil yang disediakan oleh Sun Microsystems, yaitu yang dinamakan dengan MIDP. Beberapa profil yang tersedia untuk kebutuhan-kebutuhan spesifik lainnya:

- Personal Digital Assistant Profile (PDAP), yaitu profil untuk PDA yang

memperluas fungsi-fungsi pada konfigurasi CLDC dan digunakan khusus untuk menambahkan kemampuan-kemampuan lebih apabila dibandingkan dengan penggunaan MIDP

- Foundation Profile, yaitu profil yang digunakan untuk konfgurasi CDC.

CDC, dan berperan juga dalam pondasi untuk membentuk profil baru lainnya.

- Personal Profile, yaitu profil yang mendefinisikan ulang personal Java

sebagai profil yang dapat digunakan sebagai profil dalam J2ME. Profil ini merupakan hasil perluasan dari Foundation profile

- Remote Method Invocation (RMI), yaitu profil yang menambakan

dukungan RMI ke dalam konfigurasi CDC.

2.3.4. Push Registry

Enrique (2003) mengemukakan bahwa Push Registry adalah suatu mekanisme dalam midlet untuk menghidupkan aplikasi midlet secara otomatis tanpa ada campur tangan dari pengguna, dengan mengirimkan sinyal tertentu ke

handphone sehingga aplikasi di handphone bisa hidup. Sinyal yang dikirimkan bisa

berupa sms, socket atau datagram.

Push Registry terletak di dalam klas javax.microedition.io.PushRegistry

pada MIDP 2.0. gambar 2.8 menjelaskan elemen-elemen Push Registry:

Untuk mengimplementasikan Push Registry pada aplikasi Midlet, pada file

java application descriptor (jad) dilakukan penambahan script untuk mendaftarkan

no port yang akan di-listen oleh AMS, MIDlet-Push:sms://:5000 adalah cara meregister AMS untuk mendengarkan koneksi SMS pada port 5000 dan apabila ada SMS yang masuk pada port tersebut maka SMS tidak akan masuk pada aplikasi SMS bawaan handphone melainkan AMS akan menghidupkan Midlet secara otomatis dan mengirimkan isi SMS tersebut untuk diproses oleh aplikasi Midlet.

2.3.5. Wireless Messaging API (WMA)

Raharjo dan Heryanto (2007), mengemukakan WMA adalah paket opsional yang terdapat pada J2ME, yang mengizinkan pengembang untuk mengembangkan aplikasi-aplikasi yang mampu melakukan pengiriman dan penerimaan pesan SMS dengan meng-import kelas pada paket javax.wireless.messaging.

Dalam proses pengiriman dan penerimaan pesan SMS, terdapat tiga buah

interface antara lain: TextMessage, BinaryMessage, dan MessageConnection

yang mendefinisikan method umum untuk mengeset alamat penerima dan juga mendapatkan waktu pesan. Berikut ini deklarasi dari method-method yang terdapat dalam interface message.

String getAddress() // mengambil alamat pengirim

void setAddress (String address) // mengeset alamat tujuan

Date getTimeStamp // mengambil tanggal pengiriman String getPayLoadText() // mengambil isi pesan teks void setPayloadText (String body) // menampung pesan teks byte[] getPayloadData() // mengambil isi pesan biner void setPayloadData(byte[] content)// menanmpuk pesan biner

Gambar 2.10. Syntak Interface Message

Inti dari kelas WMA berada pada interface MessageConnection, yang merepresentasikan sebuah koneksi jaringan untuk memperoleh proses pengiriman maupun penerimaan pesan dengan cara melewatkan URL tertentu ke dalam

method Connector.open().

Berikut ini aturan penulisan URL tertentu yang diizinkan di dalam WMA:

 sms://no_telepon, MessageConnection akan mengirimkan pesan ke nomor telepon tujuan. Pesan akan terkirim ke inbox SMS dari device tujuan. Dengan demikian, pesan secara otomatis akan diterima oleh aplikasi yang telah disediakan oleh device bersangkutan, bukan oleh aplikasi penerima SMS yang akan kita kembangkan sendiri.

 sms://no_telepon:port, MessageConnection akan mengirimkan pesan ke no telepon tujuan untuk port yang telah ditentukan. Di sini pesan tidak akan terkirim ke inbox SMS dari device bersangkutan melainkan akan dikirimkan ke suatau midlet pada device penerimayang bertugas mendengarkan port tertentu.

 sms://:port, MessageConnection akan mendengarkan port yang ditentukan. Midlet SMS yang berada di client berperan sebagai server pada port tertentu. Pesan akan terkirim melalui port tersebut. Koneksi jenis ini dinamakan dengan koneksi mode server.

Interface MessageConnection mendeklarasikan beberapa buah method untuk

keperluan pengiriman dan penerimaan pesan, yaitu sebagai berikut

Message newMessage(String type) // membuat tipe pesan baru int numOfSegments(Message msg) // mengambil jumlah sms Message receive() // menerima sms

void send(Message msg) // mengirim sms

void setMessageListener(MessageListener l) // mendengarkan portsms Gambar 2.11. Syntak Interface MessageConnection

Parameter type yang terdapat pada method newMessage() dapat berupa

TEXT_MESSAGE atau BINARY_MESSAGE. MessageConnection juga dapat memiliki

sebuah objek listener. Midlet yang memiliki objek listener harus mengimplementasikan interface MessageListener.

2.4 Thread

Sebuah thread adalah satuan dasar di mana sistem operasi mengalokasikan waktu prosesornya. Setiap thread menangani exception handlers, sebuah prioritas penjadwalan, dan satu set struktur di mana sistem akan menggunakannya untuk menyimpan konteks thread sampai ia terjadwal. Yang termasuk di dalam konteks

thread adalah mesin, register dan stack yang berada dalam alamat prosesnya.

Sebuah sistem operasi multitasking membagi waktu prosesor untuk proses atau thread yang membutuhkannya. Sistem mengalokasikan potongan waktu

prosesor ke setiap thread yang dieksekusi. Thread yang sedang dieksekusi akan

dijalankan. Status thread ketika terjadi pergiliran disimpan di dalam antrian. Lama potongan waktu prosesor bergantung pada sistem operasi yang bersangkutan dan juga prosesornya sendiri. Karena tiap potongan waktu itu begitu singkatnya maka

thread ganda terlihat dieksekusi pada waktu yang bersamaan. Pada umumnya

thread digunakan untuk aplikasi yang:

 Melakukan operasi yang membutuhkan waktu cukup lama.

 Membedakan task yang mempunyai prioritas berbeda-beda.

 Mempertahankan antarmuka pemakai supaya tetap responsif, selama melakukan proses background.

2.4.1. Single Thread

VLSM (2003) menyebutkan bahwa setiap program java memiliki setidaknya sebuah thread, yaitu main yang merupakan single-thread tersendiri di JVM. Java juga menyediakan perintah untuk membuat dan memodifikasi thread

tambahan sesuai Kebutuhan program.

Salah satu cara membuat thread secara eksplisit yaitu dengan membuat objek baru dari class yang telah extends class Thread. Cara lain adalah dengan

override method run dari interface Runnable. Sebuah objek yang berasal dari

subkelas Thread dapat dijalankan sebagai kontrol thread yang terpisah dalam JVM. Membuat objek dari class Thread tidak akan membuat thread baru. Akan tetapi dengan method start() akan terbentuk thread baru. Memanggil method start() untuk objek baru akan mengakibatkan 2 hal, yaitu: 1. Mengalokasikan memori dan menginisialisasi sebuah thread baru dalam JVM, 2. Memanggil method run, membuat thread dapat dijalankan oleh JVM (Catatan: Method run dijalankan jika

method start() dipanggil. Memanggil method run secara langsung hanya menghasilkan single-thread tambahan selain main. pembuatan thread dengan membuat objek baru dari class yang extends class Thread:

public class TestThread1 {

public static void main (String[] args) { BuatThread1 b = new BuatThread1();

for(int i = 0; i < angka; i++) { b.start();

} } }

class BuatThread1 extends Thread { public void run() {

try {

System.out.println("Thread baru dibuat."); }

catch (InterruptedException e) { }

} }

Gambar 2.12 Syntak Membuat Thread pada Java

2.4.2. Multi Thread

Multithreading memungkinkan suatu aplikasi memproses lebih dari satu

pekerjaan pada saat yang bersamaan. Saat menggunakan multithreading, satu

thread memproses antarmuka sementara thread lain melakukan kalkulasi-kalkulasi

intensif atau memproses di latar. Bahasa pemrograman Java memfasilitasi

multithreading, sehingga para pengembang program dapat dengan mudah

menggunakan kemudahan ini.

Cara paling mudah untuk membuat proses latar yang dapat berproses di

thread-nya sendiri dengan datanya sendiri adalah membuat suatu obyek khusus

untuk proses latar. Tujuan dilakukannya hal ini adalah baik, sepanjang dapat menyederhanakan pembuatan aplikasi multithread. Jika background thread

melakukan proses di dalam obyeknya sendiri, maka ia dapat memakai variable instan dari obyek tersebut tanpa khawatir bahwa mereka akan dipakai oleh thread

yang lain. Avestro (2007) menggambarkan perbedaan proses yang dilakukan antara

single-thread dengan multithread pada Gambar 2.13.

31

BAB III

ANALISA DAN PERANCANGAN SISTEM

3.1. Analisa

Aplikasi kompresi SMS ini dikembangkan dengan teknik mengkompresi singkatan-singkatan kata SMS yang sering dipakai dalam kehidupan sehari-hari menjadi bit-bit yang lebih pendek dari bit asalnya. Singkatan-singkatan yang sering dipakai tersebut diperoleh berdasarkan hasil kuisioner terhadap 50 orang responden yang terdiri dari mahasiswa dan masyarakat umum. Sedangkan singkatan-singkatan kata yang jarang digunakan akan dibaca karakter per karakter untuk dikompres menjadi bit-bit yang lebih pendek berdasarkan tabel huffman tetap yang telah ditentukan oleh sistem.

Untuk dekompres dilakukan dengan cara membaca karakter demi karakter deretan string biner dan dicocokkan pada tabel singkatan kata, jika ditemukan deretan bit biner yang bersesuaian dengan tabel maka bit-bit tersebut akan dikonversi menjadi singkatan kata SMS, namun apabila tidak ditemukan pada tabel singkatan kata, bit-bit tersebut akan dicocokkan dengan tabel karakter.

Selain fasilitas kompres dan dekompres, pengguna nantinya dapat mengirimkan pesan tanpa memberitahukan pihak penerima terlebih dahulu bahwa akan mengirimkan SMS karena HP yang telah ter-install aplikasi ini, secara otomatis AMS akan menghidupkan Midlet apabila terdapat SMS masuk yang dikirimkan dari aplikasi yang sama. Pada aplikasi ini nantinya akan terdapat menu untuk mengganti bahasa Inggris (default) dengan bahasa Indonesia agar pengguna lebih nyaman dalam menggunakan aplikasi ini.

3.2. Perancangan Sistem

Perancangan sistem berisikan penjelasan tentang deskripsi umum sistem, proses-proses akan dijabarkan dalam use case diagram, class diagram, activity

diagram, sequence diagram sistem dan perancangan proses latar, selain itu juga

dibuat perancangan antarmuka aplikasi.

3.2.1. Deskripsi Umum Sistem

Gambar 3.1. Arsitektur Sistem Kompresi SMS

Deskripsi dari arsitektur sistem tersebut adalah sebagai berikut :

1. Pengguna atau pengirim akan mengirimkan SMS kepada penerima melalui HP yang telah ter-install aplikasi.

2. Pengguna menjalankan aplikasi terlebih dahulu dan memilih menu tulis pesan baru, setelah itu pengirim mengetikkan pesan SMS yang secara otomatis pesan tersebut dikompresi oleh aplikasi dengan menampilkan perbandingan rasio hasil kompresinya, ketika menentukan no penerima bisa langsung mengetik sendiri atau membaca dari phone book, setelah pengguna selesai mengetikkan pesan maka pengguna dapat menekan tombol kirim (proses kompresi dilakukan pada HP pengirim)

SMS CENTER

BTS BTS

Pengirim

Penerima HP ter-install aplikasi HP ter-install aplikasi

1

2 3

4

5

6

7

8

3. Pesan dikirimkan ke SMSC melalui jaringan GSM dengan melewati beberapa BTS terlebih dulu. (pesan tidak langsung dikirimkan dari HP pengirim ke HP penerima, melainkan melalui SMSC terlebih dulu)

4. Pada BTS terakhir (BTS yang paling dekat dengan SMSC) pesan tersebut dikirimkan ke SMSC melalui jaringan kabel.

5. Pada SMSC ini pesan yang telah terkompresi disimpan sementara guna kebutuhan informasi seperti delivery report, status pending atau failed.

6. Pesan dikirimkan berdasarkan no penerima dari SMSC ke HP penerima melalui BTS terdekat pada jaringan kabel.

7. Kemudian diteruskan oleh BTS satu kepada BTS lain sampai pada BTS yang melayani jaringan HP penerima. Pesan dikirimkan kepada HP penerima melalui jaringan GSM.

8. Jika aplikasi pada HP penerima dalam keadaan tidak running, maka AMS yang mengetahui adanya SMS masuk pada port tertentu secara otomatis akan menghidupkan aplikasi serta menyimpannya dalam pesan masuk, lalu menampilkan alert kepada pengguna bahwa terdapat pesan masuk.

9. Pengguna yang menyetujui pesan masuk untuk dibaca maka secara otomatis sistem melakukan proses dekompres pada pesan tersebut dan menampilkan hasil kepada pengguna. Setelah membaca pesan, pengguna dapat melakukan

reply pada menu yang telah disediakan yang mana prosesnya pengirimannya

sama seperti pada HP pengirim.

3.2.2. Kebutuhan Sistem

Dengan mengidentifikasi arsitektur pada gambar 3.1 telah diketahui bahwa fokus utama sistem atau proses kompresi dan dekompres berada pada HP pengirim dan HP penerima, sedangkan pada BTS mapun SMSC bertindak hanya sebagai perantara saja. Dengan demikian kebutuhan sistem dapat dikategorikan menjadi 2 yaitu kebutuhan pengguna dan 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 berisideretan bit hasil konversinya.

Gambar 3.2 mengambarkan nama-nama tabel dan field-field beserta tipenya:

Setelah dilakukan kuisioner dan hasilnya diproses/dikonversi 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

Diagram berikut menjelaskan tentang aktivitas yang bisa dilakukan oleh pengguna aplikasi kompresi sms.

Gambar 3.3. Use Case diagram aplikasi Kompresi sms

Send SMS merupakan aktivitas yang dilakukan pengguna dalam

mengirimkan SMS. Untuk mengirimkan pesan pengguna mengetikkan pesan dalam

text box, kemudian memasukkan no penerima dengan cara mengetikkan pada text

field yang telah disediakan.ketika pengguna mengetik pesan dan mengirimkannya,

proses-proses ini ditangani secara multithread pada latar. Setting merupakan aktivitas pengguna untuk mengatur konfigurasi bahasa aplikasi dan pengaturan pesan masuk, pesan keluar. Receive SMS merupakan aktivitas yang akan dilakukan pengguna jika terdapat SMS masuk. Pesan yang masuk akan di-dekompres pada proses latar dengan cara mencocokkan pada tabel acuan yang telah dibuat dan menampilkan hasil dekompres pesan pada pengguna.

3.2.4. Activity Diagram

Terdapat 2 activity diagram yang perlu dijelaskan dalam sistem ini karena proses di dalam use case ini tergolong kompleks, yaitu activity diagram send sms

dan activity diagram receive sms.

Gambar 3.3. Activity Diagram send sms

Untuk mengirimkan pesan di mulai dengan membuka pilihan menu dan memilih menu pesan baru, kemudian memasukkan no tujuan penerima dengan cara langsung mengetik atau membaca dari memori telepon. Ketika pengguna mengetikkan pesan yang akan dikirimkan terdapat proses background yang bekerja yaitu untuk kompresi pesan dan menghitung rasio kompresi. Setelah pesan diketik pesan dikirimkan ke no tujuan dan otomatis tersimpan pada sent message.

Gambar 3.5. Activity Diagram receive sms

Untuk menerima pesan di mulai dengan AMS mendengarkan SMS masuk pada port yang telah ditentukan, jika tidak ada sms masuk, AMS akan menunggu terus sampai ada pesan pesan masuk, AMS akan mengecek apakah aplikasi sudah

running, jika belum maka AMS secara otomatis akan menjalankan aplikasi karena

aplikasi ini menggunakan fitur push registy, dan menyerahkan sms pada aplikasi ini. Pada form main akan ditampilkan alert bahwa ada pesan masuk, ketika pengguna membuka pesan, terdapat proses pada background yaitu proses dekompres pesan, setelah proses dekompres selesai pesan akan disimpan dalam

inbox kemudian ditampilkan isi pesan ke pengguna, bila pengguna membalas pesan

3.2.5. Class Diagram

Gambar 3.6. Class Diagram aplikasi

Pada class diagram di atas memodelkan class-class apa saja yang terlibat dalam sistem serta bagaimana interaksi antar class-class. Pada class-class tersebut juga definisikan operasi-operasi apa saja yang bisa dilakukan. Pada class

TulisPesan memiliki method untuk memasukkan no tujuan penerima dengan cara membaca dari phone book, selain itu terdapat method kirim pesan yang berinteraksi dengan class Encoder yang memiliki method untuk mengompresi pesan berdasarkan atribut pada class DataBiner dan mempunyai method inforasiokompresi. Method-method pada class Encoder dan Decoder dijalankan pada thread tersendiri yaitu pada proses background agar aplikasi tidak terhenti dan tetap responsif ketika user melakukan operasi yang lain.

3.2.6. Sequence Diagram

Gambar 3.7. Sequence Diagram Latar

Diagram di atas menunjukkan urutan proses latar yang dikerjakan.

Sequence diagram proses dimulai ketika AMS mendengarkan SMS pada port

tertentu, kemudian AMS akan mengaktifkan Midlet jika terdapat sms masuk dan ditangani oleh Class FormMain, jika SMS dibuka akan mengaktifkan method dekompres pada Class Decoder. Proses ini dilakukan pada latar yang dibangun dengan konsep thread sehingga ketika ia sedang berjalan tetap tidak akan mengganggu responsivitas antarmuka pemakai. Pesan sms yang masuk bisa jadi datang secara bersama-sama dan dalam jumlah yang cukup banyak. Untuk itu penanganannya membutuhkan kembali thread, sehingga pemrosesan pesan masuk bisa dilakukan secara simultan tanpa harus menunggu proses yang awal selesai dikerjakan terlebih dahulu oleh aplikasi.

3.2.7. Perancangan Proses Latar

Untuk menghindari terjadinya deadlock pada sistem, akan dibuat rancangan proses yang berjalan pada proses latar sehingga interaksi pengguna terhadap proses muka tetap responsif. Masing masing proses latar ini dikerjakan pada object yang berbeda sehingga satu sama lain tidak berhubungan dalam pertukaran data. Deskripsi dari proses-proses latar tersebut adalah sebagai berikut:

1. Proses Kompres, yaitu menangkap pesan bertipe string, mengkompres pesan berdasarkan tabel acuan dan menambahkan 4 bit versi pada awal string, mengubah deretan biner menjadi bertipe byte dan mengembalikan hasilnya. 2. Proses Dekompres, yaitu menangkap pesan bertipe byte, mengubah ke pesan

menjadi deretan biner, mengambil 4 bit pertama untuk menentukan tabel acuan yang akan digunakan dalam proses dekompres, hasil berupa String.

3. Proses menerima SMS, yaitu mendengarkan port-sms tertentu, mengambil tanggal pesan dikirim, melemparkan isi pesan masuk pada proses dekompres, menyimpan pesan ke inbox.

4. Proses mengirim SMS, yaitu validasi no tujuan penerima, melemparkan ke proses dekompres, mengirimkan hasil pesan dan menyimpannya ke outbox.

5. Proses mengecek jumlah karakter yang diketikkan, yaitu menghitung jumlah karakter yang sedang diketikkan, jika karakter yang diketikkan melebihi batas maksimal byte pengirimanakan ditampilkan alert kepada pengguna untuk mengurangi beberapa karakter.

6. Proses menghitung rasio hasil kompresi, ketika pengguna selesai mengetik karakter, proses ini running untuk menghitung rasio kompresi dan hasilnya ditampilkan ke pengguna.

byte[] temp = null; ByteArrayInputStream bais;

ByteArrayOutputStream baos = new ByteArrayOutputStream(); DataInputStream dis;

DataOutputStream dos = new DataOutputStream(baos); try

{

re = rs.enumerateRecords(null, null, false);

while (re.hasNextElement())

{

int i = re.nextRecordId(); rs.deleteRecord(i); }

}catch (Exception rse) {} try

{

dos.writeUTF(""+costfix.cekLanguage); temp = baos.toByteArray();

}catch (Exception er) {} try

{

rs.addRecord(temp, 0, temp.length); }catch (Exception er) {}

String set="";

if(costfix.cekLanguage==1) set=Language.eng; else

set=Language.ind; costfix.savealert = new

Alert(Language.bhs,set+Language.svd,null,AlertType.INFO); costfix.savealert.setTimeout(3000); }

}

//Outbox.java

package com.farid.costfix.net; import java.io.ByteArrayInputStream; import java.io.ByteArrayOutputStream; import java.io.DataInputStream; import java.io.DataOutputStream; import java.io.IOException; import javax.microedition.rms.*; import javax.microedition.lcdui.*; public class Outbox

{

static RecordStore rs;

static RecordEnumeration re; public Outbox(){}

static String tabel[][] = new String[100][4]; static int n=0;

public static void openFile() {

rs = null; try {

rs = RecordStore.openRecordStore("outbox", true); }

catch (Exception er){} }

public static void tambahRecord(String noTelp, String isiPesan,String tgl,String stat)

{

openFile(); byte[] temp = null; try

{

ByteArrayOutputStream baos = new ByteArrayOutputStream(); DataOutputStream dos = new DataOutputStream(baos); dos.writeUTF(noTelp);

dos.writeUTF(tgl); dos.writeUTF(stat);

temp = baos.toByteArray();

rs.addRecord(temp, 0, temp.length); }catch (Exception ioe){}

}

public static void hapusRecord(String not, String Tgl) {

openFile(); byte[] temp = null; try

{

boolean ok = true;

re = rs.enumerateRecords(null, null, false); while (re.hasNextElement() && ok == true) {

int i = re.nextRecordId();

temp = rs.getRecord(i);

ByteArrayInputStream bais = new ByteArrayInputStream(temp);

DataInputStream dis = new DataInputStream(bais); try

{

String noTelp = dis.readUTF();

String isiPesan = dis.readUTF();

String tgl = dis.readUTF();

String stat = dis.readUTF();

if (noTelp.equals(not)&&tgl.equals(Tgl))

{

rs.deleteRecord(i); re.rebuild();

ok = false;

}

}catch (Exception ioe) {} }

cekOutbox();

}catch(Exception er){}

}

public static void updateRecord(String not, String isiPesan, String Tgl) {

hapusRecord(not,Tgl);

tambahRecord(not,isiPesan,Tgl,"sudah"); }

public static void outbox() {

openFile(); byte[] temp = null;

costfix.listOutbox = new List(Language.msm, Choice.IMPLICIT); costfix.listOutbox.deleteAll();

for(int i=0; i<100; i++) {

tabel[i][0]=""; tabel[i][1]=""; tabel[i][2]=""; tabel[i][3]=""; }

n = 0;

try {

re = rs.enumerateRecords(null, null, false);

while (re.hasNextElement())

{

int i = re.nextRecordId();

temp = rs.getRecord(i);

ByteArrayInputStream bais = new ByteArrayInputStream(temp);

DataInputStream dis = new DataInputStream(bais); try

{

String isiPesan = dis.readUTF();

String tgl = dis.readUTF();

String stat = dis.readUTF();

tabel[n][0] = noTelp;

tabel[n][1] = isiPesan;

tabel[n][2] = tgl;

tabel[n][3] = stat;

if(tabel[n][3].equals("sudah")) costfix.listOutbox.append(tabel[n][0], Kosmetik.img12);

else if(tabel[n][3].equals("belum"))

costfix.listOutbox.append(tabel[n][0], Kosmetik.img13); n++;

} catch (Exception er) {} }

if(n==0)

costfix.listOutbox.append(Language.emp,null); else

costfix.listOutbox.addCommand(costfix.cmdViewOut); costfix.listOutbox.addCommand(costfix.cmdKembali);

}catch(Exception er){}

}

public static void cekOutbox() {

openFile(); byte[] temp = null;

n = 0;

int nH = 0; try

{

re = rs.enumerateRecords(null, null, false);

while (re.hasNextElement())

{

int i = re.nextRecordId();

temp = rs.getRecord(i);

ByteArrayInputStream bais = new ByteArrayInputStream(temp);

DataInputStream dis = new DataInputStream(bais); try

{

String noTelp = dis.readUTF();

String isiPesan = dis.readUTF();

String tgl = dis.readUTF();

String stat = dis.readUTF();

tabel[n][0] = noTelp;

tabel[n][1] = isiPesan;

tabel[n][2] = tgl;

tabel[n][3] = stat;

nH++;

if(tabel[n][3].equals("belum")) n++;

} catch (Exception er) {} }

costfix.nMo = n;

costfix.nOut = nH;

}catch(Exception er){}

} }

//Settings.java

package com.farid.costfix.net; import javax.microedition.lcdui.*; class Settings

{

public void Settings(){} public static void settings() {

if(costfix.cekLanguage==1)

set=Language.bhs+" "+Language.mst; else

set=Language.mst+" "+Language.bhs; costfix.listSettings = new List(set, Choice.EXCLUSIVE);

costfix.listSettings.append(Language.eng, Kosmetik.img7); costfix.listSettings.append(Language.ind, Kosmetik.img8);

costfix.listSettings.setSelectedIndex(costfix.cekLanguage-1,true); costfix.listSettings.addCommand(costfix.cmdPilihBahasa);

costfix.listSettings.addCommand(costfix.cmdKembali); }

}

//Tips.java

package com.farid.costfix.net; import javax.microedition.lcdui.*; class Tips

{

public void Tips(){}

public static void showTips() {

costfix.tipsForm = new Form(Language.tps); String kata = Language.tus;

DataKata dk = new DataKata(); for(int i=0; i<32; i++) {

kata += (i+1)+". "+dk.kata[i]+"\n"; }

costfix.tipsForm.append(kata);

costfix.tipsForm.addCommand(costfix.cmdKembali); }

}

//WriteNew.java

package com.farid.costfix.net; import javax.microedition.lcdui.*; import javax.wireless.messaging.*; import javax.microedition.io.*; import java.util.Calendar;

class WriteNew implements Runnable {

private static Thread threadKirim; public void WriteNew(){}

public static void setBox(String no, String pesan) {

if(no.equals("baru"))

costfix.NoTujuan = new TextField(Language.ntj, null, 15, TextField.PHONENUMBER);

else

costfix.NoTujuan = new TextField(Language.ntj, no, 15, TextField.PHONENUMBER);

if(pesan.equals("baru"))

costfix.pesanTeks = new TextBox(null, null, 900, TextField.ANY);

else

costfix.pesanTeks = new TextBox(null, pesan, 900, TextField.ANY);

costfix.wnForm = new Form("costfix");

costfix.pesanTeks.addCommand(costfix.cmdContinue); costfix.pesanTeks.addCommand(costfix.cmdKembali); }

public static void setForm() {

InfoKompresi ifk = new InfoKompresi(); ifk.infoKompresi();

costfix.wnForm.addCommand(costfix.cmdKembaliTik); }

public void run() {

MessageConnection con = null;

String alamat = "sms://"+costfix.NoTujuan.getString()+":2007"; try

{

Outbox.tambahRecord(costfix.NoTujuan.getString(),costfix.pesanTeks.getString (),getTanggal(),"belum");

con = (MessageConnection) Connector.open(alamat); BinaryMessage bm = (BinaryMessage)

con.newMessage(MessageConnection.BINARY_MESSAGE); bm.setAddress(alamat);

String a = costfix.pesanTeks.getString(); byte b[] = Encoder.kompres(a);

String c = Decoder.dekompres(b); if(a.equals(c))

bm.setPayloadData(b); else

bm.setPayloadData(Encoder.kompresDarurat(a)); con.send(bm);

if(con!=null) con.close();

costfix.alertTerkirim = new Alert(null,Language.snt,Kosmetik.img3,AlertType.INFO);

costfix.alertTerkirim.setTimeout(3000);

costfix.display.setCurrent(costfix.alertTerkirim);

}catch(Exception er)

{

costfix.alertTerkirim = new Alert(null,Language.ggl,Kosmetik.img14,AlertType.INFO);

costfix.alertTerkirim.setTimeout(Alert.FOREVER); costfix.display.setCurrent(costfix.alertTerkirim);

}

}

public void sendSMS() {

threadKirim = new Thread(this);

threadKirim.start();

}

public String tambahNol(int i){ String s = String.valueOf(i); if(s.length() == 1)

return "0"+s;

else if(s.length() == 2)

return s;

else

return "";

}

public static String tambahNol2(int i){ String s = String.valueOf(i); if(s.length() == 1)

return "0"+s;

else if(s.length() == 2)

return s;

else

return "";

}

public String getTanggal() {

Calendar tanggal = Calendar.getInstance(); String hasil = "";

hasil += tanggal.get(Calendar.DATE)+"-"; switch(tanggal.get(Calendar.MONTH))

{

case 0 : hasil += "Jan"; break; case 1 : hasil += "Feb"; break;

case 2 : hasil += "Mar"; break; case 3 : hasil += "Apr"; break; case 4 : hasil += "May"; break; case 5 : hasil += "Jun"; break; case 6 : hasil += "Jul"; break; case 7 : hasil += "Aug"; break; case 8 : hasil += "Sep"; break; case 9 : hasil += "Okt"; break; case 10 : hasil += "Nov";break; case 11 : hasil += "Dec"; break;

default : break;

}

hasil += "-"+tanggal.get(Calendar.YEAR); hasil += " ";

hasil += tambahNol(tanggal.get(Calendar.HOUR)); hasil += ":";

hasil += tambahNol(tanggal.get(Calendar.MINUTE)); hasil += ":";

hasil += tambahNol(tanggal.get(Calendar.SECOND)); return(hasil);

}

public static String getTanggale() {

Calendar tanggal = Calendar.getInstance(); String hasil = "";

hasil += tanggal.get(Calendar.DATE)+"-";

switch(tanggal.get(Calendar.MONTH))

{

case 0 : hasil += "Jan"; break; case 1 : hasil += "Feb"; break; case 2 : hasil += "Mar"; break; case 3 : hasil += "Apr"; break; case 4 : hasil += "May"; break; case 5 : hasil += "Jun"; break; case 6 : hasil += "Jul"; break; case 7 : hasil += "Aug"; break; case 8 : hasil += "Sep"; break; case 9 : hasil += "Okt"; break; case 10 : hasil += "Nov";break; case 11 : hasil += "Dec"; break;

default : break;

}

hasil += "-"+tanggal.get(Calendar.YEAR); hasil += " ";

hasil += tambahNol2(tanggal.get(Calendar.HOUR)); hasil += ":";

hasil += tambahNol2(tanggal.get(Calendar.MINUTE)); hasil += ":";

hasil += tambahNol2(tanggal.get(Calendar.SECOND)); return(hasil);

} }