1
ANALISIS DAN PERANCANGAN
3.1 Metodologi
Pembangunan Perangkat Lunak
Pembangunan perangkat lunak pada Tugas Akhir ini menggunakan metodologi unified
process sebagaimana yang disebutkan pada Subbab 1.5. Pada keempat fase pada unified process dilakukan beberapa iterasi sesuai kebutuhan. Keterhubungan fase, aktivitas dalam
fase tertentu dan deliverables dari aktivitas terkait selama pembangunan aplikasi terdapat pada Tabel III-1.
Tabel III-1 Keterhubungan fase, aktivitas, dan deilverables dalam Pembangunan Kakas
Fase Aktivitas Deliverables
Inception Analisis domain masalah 1. Hasil analisis domain
Analisis perangkat lunak 2. Diagram use case
Elaboration Analisis domain masalah 3. Revisi hasil analisis domain
Analisis perangkat lunak 4. Revisi diagram use case 5. Skenario use case 6. Diagram sequence
7. Identifikasi paket dan kelas analisis Perancangan perangkat lunak 8. Perancangan antarmuka
9. Perancangan subsistem 10. Diagram deployment 11. Throw-away prototype 12. Identifikasi kelas peracangan Implementasi perangkat lunak 13. Kode program
Construction Perancangan perangkat lunak 14. Revisi identifikasi kelas perancangan
15. Revisi perancangan antarmuka 16. Revisi perancangan subsistem 17. Revisi diagram deployment Implementasi perangkat lunak 18. Revisi kode porgram Pengujian terintegrasi 19. Evaluasi pengujian
Transition Persiapan instalasi 20. Installer aplikasi
3.2 Analisis
Domain
Masalah
Analisis domain masalah yang dibahas meliputi perbandingan teknologi penentuan posisi, kebutuhan aplikasi berbasis lokasi, analisis kebutuhan teknologi mobile positioning untuk aplikasi Muslim Prayer Time, dan teknologi mobile positioning untuk aplikasi Muslim Prayer
Time.
3.2.1 Perbandingan Teknologi Mobile Positioning
Setiap teknologi harus dievaluasi kelebihan dan kelemahannya bagi suatu aplikasi dengan cara mempertimbangkan performansi, implementasi, dan biaya yang dibutuhkan. Berikut ini
pembahasan perbandingan teknologi mobile positioning berdasarkan jenis-jenis pengukuran yang disebutkan pada Tabel II-1, Tabel II-2, dan Tabel II-3.
3.2.1.1 Perbandingan Teknologi Mobile Positioning Berdasarkan Performansinya.
Pengukuran implementasi didasarkan pada hasil pengukuran posisi (yield), konsistensi hasil pengukuran yang diperoleh, akurasi posisi, dan start time. Penjelasan masing-masing ukuran performansi dapat dilihat pada tabel Tabel II-1. Rangkuman perbandingan teknologi mobile
positioning berdasarkan performansi dapat dilihat pada Tabel III-2.
1. Hasil pengukuran posisi (yield)
Untuk melakukan pengukuran posisi, Cell ID hanya membutuhkan satu base station sedangkan E-OTD dan OTDOA membutuhkan minimal tiga base station/Node B. A-GPS dan Hibrid yang menggunakan satelit, membutuhkan empat satelit untuk melakukan pengukuran posisi. Pada area pedesaan, Cell ID, E-OTD dan OTDOA memberikan hasil posisi yang buruk. Pada Cell ID, hasil yang buruk ini disebabkan oleh jarak BTS yang jauh dari pengguna sedangkan pada E-OTD dan OTDOA, hal ini dikarenakan sedikitnya BTS untuk dilakukan pengukuran posisi. A-GPS memberikan hasil buruk di lingkungan dalam gedung atau indoor karena dibutuhkan kondisi line
of sight. Untuk mengatasi masalah ini, A-GPS dapat dikombinasikan dengan Cell ID
sehingga apabila bermasalah ketika berada di dalam gedung maka pengukuran posisi dapat digantikan oleh Cell ID.
2. Konsistensi hasil pengukuran yang diperoleh
Pada lingkungan yang berbeda, Cell ID, E-OTD dan OTDOA memberikan hasil yang tidak konsisten. Pada Cell ID, hasil yang tidak konsisten ini disebabkan oleh perbedaan ukuran sel, kepadatan jaringan dan karateristik operasional jaringan. Sebaliknya A-GPS dan Hibrid memberikan konsistensi hasil di tempat manapun dan dalam jaringan apapun.
3. Akurasi posisi
Cell ID memberikan tingkat akurasi mulai dari 500m sampai 20km pada lingkungan
GSM dan 100m sampai 5km pada lingkungan UMTS tergantung pada kepadatan jaringan dan cakupun sel. E-OTD dan OTDOA memberikan tingkat akurasi yang lebih baik dibandingkan Cell ID yaitu 100m sampai 500m. A-GPS dan Hibrid memberikan hasil akurasi terbaik dibandingkan teknologi lain yang dibahas pada Tugas Akhir ini, yaitu 5 – 50m. Kelebihan lain A-GPS dan Hibrid adalah keduanya
menghasilkan posisi berdimensi tiga (garis lintang, garis bujur, dan ketinggian) sedangkan teknologi lainnya hanya menghasilkan posisi berdimensi dua.
Untuk memperbaiki akurasinya, Cell ID dapat dikombinasikan dengan TA (Time
Advance) atau RTT (Round Trip Time). TA dan RTT menggunakan waktu saat
pengiriman informasi dari BTS/Node B menuju mobile handset untuk menentukan jarak MS/UE ke BTS/Node B.
4. Start time
Arti start time ini adalah waktu yang dibutuhkan untuk melakukan pengukuran posisi.
Cell ID memberikan start time terpendek yaitu sekitar 1 detik sedangkan teknologi
lain memberikan start time 5 sampai 10 detik.
Tabel III-2 Rangkuman Perbandingan Mobile Positioning Posisi Berdasarkan Performansinya
Ukuran Cell ID E-OTD OTDOA A-GPS Hibrid
Yield Buruk pada
area pedesaan Buruk pada area pedesaaan Buruk pada area pedesaaan Buruk di dalam gedung Relatif baik
Konsistensi Tidak konsisten Tidak
konsisten Tidak konsisten konsisten Konsisten Akurasi posisi GSM : 500m – 20km UMTS : 100m – 5km 100m - 500m 100m - 500m 5m – 50m 5m – 50m
Start time 1 detik 5 – 10 detik 5 – 10 detik 5 – 10 detik 5 – 10 detik
3.2.1.2 Perbandingan Teknologi Mobile Positioning Berdasarkan Implementasinya.
Pengukuran implementasi didasarkan pada pengaruh pada handset, kapabilitas roaming, efisiensi jaringan, ekspansi jaringan, dan kompatibilitas jaringan. Penjelasan masing-masing ukuran implementasi dapat dilihat pada Tabel II-2. Rangkuman perbandingan teknologi
mobile positioning berdasarkan implementasi dapat dilihat pada Tabel III-3.
1. Pengaruh pada handset
Cell ID tidak membutuhkan perubahan pada handset dan tidak mengkonsumsi baterai
terlalu besar. E-OTD dan OTDOA membutuhkan perubahan software pada handset dan minimal mengkonsumsi baterai. A-GPS dan Hibrid membutuhkan perubahan software dan hardware juga penggunaan baterai yang cukup besar.
2. Kapabilitas roaming
Cell ID, A-GPS, dan Hibrid membutuhkan dukungan Location Server untuk roamed-to-network sedangkan E-OTD dan OTDOA membutuhkan tambahan alat baru yaitu
LMU (Location Measurement Unit).
3. Efisiensi jaringan
Cell ID, A-GPS, dan Hibrid menggunakan minimal bandwidth dan kapasitas jaringan
sedangkan E-OTD dan OTDOA membutuhkan bandwith dan kapasitas jaringan untuk pengoperasian LMU.
4. Ekpansi jaringan
Cell ID, A-GPS, dan Hibrid mendukung untuk perluasan jaringan tanpa dibutuhkan
usaha yang besar. Pada E-OTD dan OTDOA, perluasan jaringan berarti harus memperbanyak LMU yang terpasang pada BTS.
5. Kompatibilitas jaringan
Cell ID, A-GPS dan Hibrid dapat diterapkan pada jaringan GSM, GPRS, dan UMTS.
E-OTD hanya dapat diterapkan pada jaringan GSM dan GPRS sedangkan OTDOA hanya dapat diterapkan pada jaringan UMTS.
Tabel III-3 Rangkuman Perbandingan Mobile Positioning Posisi Berdasarkan Implementasinya
Ukuran Cell ID E-OTD OTDOA A-GPS Hibrid
Pengaruh pada handset
Tidak ada Butuh software khusus Butuh software khusus Butuh software dan hardware khusus Butuh software dan hardware khusus Kapabilitas roaming Dukungan LS Dukungan LMU Dukungan LMU Dukugan LS Dukungan LS Efisiensi jaringan Minimal bandwidth dan kapasitas Bandwidth untuk pengoperasian LMU Bandwidth untuk pengoperasian LMU Minimal bandwidth dan kapasistas Minimal bandwidth dan kapasistas Ekspansi jaringan Mendukung Butuh perluasan LMU Butuh perluasan LMU Mendukung Mendukung Kompatibilitas jaringan Seluruh jaringan GSM/GPRS UMTS Seluruh jaringan Seluruh jaringan
3.2.1.3 Perbandingan Teknologi Mobile Positioning Berdasarkan Biayanya. Pengukuran biaya didasarkan pada biaya handset, biaya infrastruktur, biaya ekspansi, biaya pemeliharaan, timing of Expenditures,dan Return of Investment. Penjelasan masing-masing ukuran biaya dapat dilihat pada Tabel II-3. Rangkuman perbandingan teknologi mobile
positioning berdasarkan biaya dapat dilihat pada Tabel III-4.
1. Biaya handset
Cell ID tidak mengeluarkan biaya handset karena tidak adanya modifikasi pada
handset. E-OTD dan OTDOA mengeluarkan biaya handset untuk keperluan pembelian software khusus yang mendukung pengukuran lokasi. A-GPS membutuhkan tambahan sirkuit GPS pada handset sehingga cukup mengeluarkan biaya.
2. Biaya infrastruktur
Cell ID dan A-GPS hanya mengeluarkan biaya infrastruktur untuk keperluan software location server karena tidak adanya modifikasi pada infrastruktur jaringan. E-OTD
dan OTDOA mengeluarkan biaya infrastruktur tergantung pada besarnya deployment. Kedua teknologi ini bekerja pada jaringan asynchronous. Banyaknya LMU yang harus dipasang pada base station tergantung pada cakupan lokasi yang diinginkan. Operator umumnya memiliki banyak base station sehingga dibutuhkan biaya pemasangan LMU yang cukup besar. Juga diperlukan perencanaan dan analisis agar menyakinkan tambahan unit tersebut tidak konflik dengan karakteristik RF yang telah ada pada jaringan. Juga terdapat tambahan biaya untuk modifikasi menara BTS dalam menempatkan peralatan baru.
3. Biaya ekspansi
Cell ID dan A-GPS tidak mengeluarkan biaya ekspansi. Sebaliknya E-OTD dan
OTDOA mengeluarkan biaya tinggi karena ketika jaringan diperluas, maka diperlukan LMU pada mayoritas BTS.
4. Biaya pemeliharaan
Cell ID dan A-GPS tidak mengeluarkan biaya pemeliharaan. Sebaliknya E-OTD dan
5. Timing of Expenditure
Cell ID tidak mengeluarkan biaya untuk deployment. Sebaliknya pada E-OTD dan
OTDOA, investasi deployment LMU kedepan sangat besar. Meskipun terdapat sedikit pelanggan yang meminta layanan lokasi, seluruh cakupan wilayah harus terdapat LMU. A-GPS mengeluarkan biaya yang murah dan fleksibel karena jika sedikit pelanggan, maka hanya handset mereka saja yang membutuhkan sirkuit GPS, sehingga biaya ini tergantung pada pertumbuhan pelanggan.
6. Biaya keseluruhan
Cell ID memiliki tingkat biaya yang relatif rendah. Sebaliknya E-OTD dan OTDOA
memiliki tingkat biaya yang tinggi baik untuk penerapan awalnya maupun pemeliharaannya. A-GPS memiliki tingkat biaya rendah sampai menengah tergantung penggunaan sirikuit A-GPS.
Tabel III-4 Rangkuman Perbandingan Teknologi Mobile Positioning Berdasarkan Biayanya
Ukuran Cell ID E-OTD OTDOA A-GPS Hibrid
Biaya handset
Tidak ada Biaya software biaya software biaya sirkuit GPS Biaya sirkuit GPS Biaya infrastruktur
Biaya LS Biaya LMU Biaya LMU Biaya LS Biaya LS
Biaya ekspansi
Tidak ada Biaya perluasan LMU
Biaya perluasan LMU
Tidak ada Tidak ada
Biaya pemeliharan
Tidak ada Biaya
Maintanance LMU Biaya Maintanance LMU Dapat diabaikan Dapat diabaikan Timing of Expenditure
Tidak ada Investasi LMU Investasi LMU Biaya murah dan fleksibel Biaya murah dan fleksibel Biaya Keseluruhan Sangat rendah
Tinggi Tinggi Rendah – menengah
Rendah - menengah
3.2.2 Kebutuhan Aplikasi Berbasis Lokasi
Cell ID dapat digunakan untuk aplikasi berbasis lokasi yang membutuhkan akurasi mencapai
500m, yield 80% dan biaya implementasi rendah. Contoh aplikasi jenis ini adalah aplikasi yang menawarkan layanan informasi dasar seperti informasi kota, kabupaten, restoran terdekat dan informasi lain yang sejenis. Kelemahan Cell ID untuk aplikasi jenis ini adalah penggunaannya hanya dapat bekerja baik pada lingkungan indoor atau urban. Cell ID tidak cocok digunakan untuk aplikasi berbasis lokasi yang membutuhkan akurasi yang tinggi.
E-OTD dan OTDOA dapat digunakan untuk aplikasi berbasis lokasi yang membutuhkan akurasi mencapai 50m dan yield sebesar 80%-99,99%. Contoh aplikasi jenis ini adalah
aplikasi tracking, games, management, leisure, billing, dan emergency. Serupa dengan Cell
ID, E-OTD dan OTDOA hanya dapat bekerja baik pada lingkungan indoor atau urban.
A-GPS dapat digunakan untuk aplikasi navigasi yang membutuhkan konsistensi akurasi yang tinggi. A-GPS dapat digunakan dengan baik pada lingkungan dimana teknologi mobile
positioning lainnya tidak dapat bekerja dengan baik karena A-GPS menggunakan satelit untuk
pengukuran posisinya. Karena A-GPS tidak mendukung legacy handset, maka dibutuhkan handset khusus dengan harga yang cukup mahal. A-GPS juga tidak mendukung di dalam gedung besar tetapi hal ini dapat diatasi dengan mengkombinasikan dengan teknologi mobile
positioning lain. Oleh karena itu, implementasi A-GPS tidak banyak digunakan dalam
aplikasi handset.
3.2.3 Analisis Kebutuhan Teknologi Mobile Positioning untuk Aplikasi
Muslim Prayer Time
Pada Tugas Akhir ini mengambil studi kasus aplikasi muslim prayer time yang berfungsi menampilkan jadwal waktu shalat dimana pengguna berada. Layanan berbasis lokasi yang ditawarkan adalah jadwal waktu shalat berdasarkan lokasi pengguna. Layanan tambahan aplikasi muslim prayer time adalah informasi lokasi masjid terdekat dari lokasi dimana pengguna berada.
3.2.3.1 Karakteristik Waktu Sholat
Untuk memahami jadwal waktu sholat lebih jauh, berikut ini dijelaskan karateristiknya, yaitu: 1. Penentuan waktu sholat didasarkan pada “pergerakan matahari” dilihat dari bumi.
Pada zaman dahulu, waktu sholat ditentukan berdasarkan observasi terhadap gejala alam dengan melihat langsung matahari.
2. Jadwal waktu sholat disusun untuk kurun waktu selama 1 tahun dan dapat dipergunakan lagi pada tahun berikutnya.
3. Waktu sholat bergeser dari hari ke hari. Hal ini diakibatkan pergerakan semu matahari 23,5˚ ke utara dan 23,5˚ ke selatan selama periode 1 tahun.
Sebenarnya penentuan waktu sholat didasarkan pada posisi matahari terhadap bumi. Hal ini menyebabkan setiap tempat akan memiliki perbedaan waktu sholat, tetapi kecenderungan di masyarakat hari ini adalah penentuan waktu sholat diberlakukan untuk satu kota atau kabupaten sehingga dalam satu kota atau kabupaten memiliki jadwal sholat yang sama.
Berdasarkan konsep waktu menggunakan posisi matahari secara astronomis para ahli kini berusaha membuat formulasi berdasarkan letak geografis dan ketinggian suatu tempat di permukaan bumi dalam bentuk sebuah program komputer yang dapat membangkitkan sebuah tabulasi data secara akurat dalam sebuah ”Jadwal Waktu Sholat”. Kini software waktu shalat terus dibuat dan dikembangkan diantaranya: Accurate Times, Athan Software, Prayer Times,
Mawaqit, Sholat Time, dan sebagainya.
3.2.3.2 Kebutuhan Aplikasi Muslim Prayer Time
Aplikasi Muslim Prayer Time ditujukan untuk pengguna yang membutuhkan informasi waktu sholat atau lokasi masjid terdekat melalui handphone-nya. Pengguna tersebut baik orang yang menetap di suatu tempat ataupun orang yang dalam perjalanan. Orang yang dalam perjalanan umumnya lebih membutuhkan informasi ini karena ia tidak mengenal daerah tempat ia sekarang berada. Dengan adanya aplikasi Muslim Prayer Time pada handphone memudahkan pengguna untuk mengetahui informasi tersebut. Agar aplikasi ini dapat digunakan secara umum oleh masyarakat maka biaya aplikasi diharapkan dapat dijangkau oleh umumnya masyarakat baik itu biaya software maupun biaya peralatan tambahan yang dibutuhkan.
Berdasarkan karakteristik jadwal sholat dan kebutuhan aplikasi tersebut dapat dirangkum kebutuhan performansi, implementasi dan biaya aplikasi muslim prayer time pada Tabel III-5.
Tabel III-5 Performansi, Implementasi, dan biaya aplikasi Muslim Prayer Time
Kriteria Komentar
Yield Waktu sholat dapat ditentukan dimanapun berada meskipun di
lingkungan yang sulit sekalipun
Konsistensi Waktu sholat harus konsisten pada lingkungan yang berbeda dan jaringan yang berbeda.
Akurasi Akurasi waktu sholat mencapai 20 km dan membutuhkan posisi berdimensi tiga (termasuk ketinggian). Akurasi lokasi masjid terdekat mencapai 500m.
Start Time Waktu sholat harus dapat diperoleh dalam hitungan detik.
Handset Aplikasi tidak membutuhkan tambahan peralatan pada handset untuk
meminimalkan biaya yang dikeluarkan
Roaming Aplikasi ini mendukung roaming pada area geografis yang luas,
memasuki jaringan lain atau jaringan yang berbeda.
Efisiensi jaringan Aplikasi hanya membutuhkan bandwidth kecil.
Ekspansi jaringan Aplikasi tetap dapat mendukung meskipun terjadi ekspansi jaringan
Kompatibilitas Aplikasi mendukung diterapkan pada jaringan GSM, GPRS, atau
UMTS.
3.2.4 Teknologi Mobile Positioning untuk Aplikasi Muslim Prayer Time
Berdasarkan pada analisis perbandingan teknologi mobile positioning yang telah dibahas, teknologi mobile positioning yang sesuai diterapkan pada aplikasi muslim prayer time adalah teknologi Cell ID dengan pertimbangan sebagai berikut:
1. Akurasi waktu sholat dapat mencapai 20 km Hal ini dapat dipenuhi oleh teknologi
Cell ID yang memiliki akurasi 500m sampai 20 km pada jaringan GSM.
2. Akurasi lokasi masjid terdekat mencapai 500m. Untuk mendapatkan akurasi posisi kurang dari 500m dengan menggunakan teknologi Cell ID dibutuhkan maksimal tiga
cell id. Apabila satu cell id memiliki cakupan satu lingkaran penuh, maka tiga cell id
akan membentuk irisan ketiga lingkaran dengan cakupan yang lebih kecil.
3. Biaya aplikasi dapat dijangkau oleh umumnya masyarakat. Hal ini juga dipenuhi oleh teknologi Cell ID yang tidak membutuhkan perubahan pada handset atau perubahan infrastruktur jaringan.
Dibandingkan dengan teknologi mobile positioning lain yang dibahas pada Tugas Akhir ini,
Cell ID memiliki keuntungan yang lebih dibandingkan dengan teknologi lainnya untuk kasus
penerapan Aplikasi Muslim Prayer Time. Hal ini dijabarkan sebagai berikut:
1. Teknologi OTDOA dan E-OTD membutuhkan kerjasama dengan pihak network
provider sedangkan teknologi Cell ID tidak. Karena dalam pengerjaan Tugas Akhir
ini tidak berhubungan dengan pihak network provider¸ maka teknologi OTDOA dan E-OTD akan sulit untuk diterapkan.
2. Meskipun teknologi A-GPS dapat menghasilkan posisi berdimensi tiga (termasuk ketinggian) yang dibutuhkan untuk penghitungan waktu sholat dibandingkan dengan teknologi Cell ID yang hanya dapat menghasilkan posisi berdimensi dua, teknologi ini membutuhkan biaya tambahan untuk pembelian peralatan GPS yang tertanam pada mobile phone.
3.2.5 Cara Mendapatkan Cell ID
Sinyal GSM memiliki banyak informasi. Cell id merupakan salah satu informasi yang terdapat pada sinyal Base Transceiver Station (BTS). Sinyal ini digunakan untuk memeriksa apakah mobile phone terhubung dengan BTS atau tidak. Perusahan telekomunikasi memiliki BTS yang berbeda. Pada Tugas Akhir ini dipilih BTS Indosat untuk diimplementasikan.
Selain informasi Cell ID, informasi lokasi lain yang dapat diperoleh dari sinyal BTS adalah MCC (Mobile Country Code), MNC (Mobile Network Code), dan LAC (Location Area
perbedaan pada MNC, LAC, dan Cell ID yang unik untuk setiap BTS. Informasi sinyal BTS dapat digambarkan pada Gambar III-1.
Gambar III-1 Informasi Sinyal BTS [LEI05]
Sebuah mobile phone secara periodik harus mengukur kekuatan sinyal dari base station yang terdekat. Berdasarkan pada pengukuran tersebut, mobile phone memilih satu sel yang memberikan penangkapan sinyal terbaik. Setelah terhubung dengan sel tersebut, mobile phone dapat mengakses layanan yang disediakan. Tetapi, ketika mobile phone bergerak, kekuatan sinyal yang diterima dari base station yang saat itu sedang terhubung menjadi menurun, hal ini dikarenakan beberapa alasan seperti karena menjauh dari base station tersebut atau disana terdapat faktor lingkungan yang dapat mengubah penangkapan sinyal. Pada situasi ini, mobile
phone harus memilih kembali sel lain yang memberikan kekuatan sinyal lebih baik. Mobile phone akan berpindah dari satu sel ke sel lain yang memiliki lac dan cell id yang berbeda.
Untuk mendapatkan Cell ID pada aplikasi, bahasa pemrograman Python menyediakan library
location untuk mendukung perolehan Cell ID.
Untuk mengumpulkan Cell ID, dilakukan tes pada beberapa masjid di Bandung selama 1 menit untuk mendapatkan sample. Metode yang digunakan dengan berdiri di tempat tersebut dan tidak bergerak. Untuk mengumpulkan Cell ID, digunakan software CellTrack untuk mempermudah perolehan Cell ID. Berikut ini adalah beberapa hasil dari beberapa tempat masjid di Bandung:
1. Masjid Salman ITB [13383, 13382]
2. Masjid Al Muhajirin Sadang Serang [12183, 12193, 13244] 3. Masjid Manunggal Sadang Subur [12193, 12196] 4. Masjid As Sunnah Sadang Luhur [12281, 12284] 5. Masjid Istiqlal Tubagus Ismail Raya [12281, 12284, 12286]
Kesimpulan dari hasil tersebut adalah pada tempat yang sama dapat terkumpul satu atau lebih
Cell ID, dan Cell ID yang sama muncul pada tempat/masjid yang berbeda.
3.3 Analisis
Perangkat
Lunak
3.3.1 Deskripsi Perangkat LunakMobile Phone
HTTP Server
Web Server
Database HTTP
Gambar III-2 Gambaran Umum Sistem
Aplikasi yang dibangun pada Tugas Akhir ini diberi nama “PrayLook”. “PrayLook” merupakan aplikasi layanan berbasis lokasi yang dapat membantu pengguna dalam memberikan informasi waktu sholat sesuai posisi pengguna sekarang berada dan informasi masjid terdekat yang dapat dijangkau oleh pengguna dari lokasinya. Informasi waktu sholat meliputi waktu sholat shubuh, dzuhur, ashar, magrib dan isya dalam bentuk jam-menit-detik sedangkan informasi masjid terdekat berupa alamat masjid tersebut.
Gambar III-2 memberikan gambaran umum sistem. Pertama pengguna meminta layanan informasi waktu sholat atau masjid terdekat kemudian mobile application menentukan sel id
mobile saat itu. Setelah mendapatkan sel id, mobile application melakukan query data pada location server. Di location server, web application akan menentukan koordinat posisi
pengguna berdasarkan sel id dan menghitung waktu sholat berdasarkan koordinat tersebut. Apabila pengguna meminta layanan masjid terdekat, maka web application menentukan masjid yang terdekat dengan pengguna. Pengguna juga dapat menjalankan alarm waktu sholat dengan otomatis update waktu sholat apabila pengguna berpindah tempat (memiliki sel id yang berbeda).
3.3.2 Analisis Kebutuhan Perangkat Lunak
Berdasarkan analisis domain masalah pada Subbab 3.2, dibutuhkan aplikasi Muslim Prayer
1. Penentuan sel ID mobile phone.
Aplikasi Muslim Prayer Time memilih teknologi Cell ID untuk menentukan posisi handset atau mobile phone. Posisi relatif handset didapatkan dari posisi BTS. Setiap BTS memiliki cell ID yang unik. Oleh karena itu dengan mendapatkan cell id pada aplikasi
Muslim Prayer Time dapat ditentukan lokasi dan waktu sholat pada lokasi tersebut.
Asumsi implementasi fitur aplikasi ini adalah koordinat BTS tersedia. 2. Penentuan waktu sholat yaitu waktu shubuh, dzuhur, ashar, magrib, dan isya.
Fitur utama aplikasi Muslim Prayer Time adalah memberikan informasi waktu sholat berdasarkan waktu dan tempat dimana pengguna berada sekarang. Penentuan waktu sholat dilakukan dengan menggunakan standar rumus yang telah umum digunakan. 3. Alarm waktu sholat
Apabila telah tiba waktu sholat, aplikasi Muslim Prayer Time akan memberikan peringatan kepada user berupa suara/audio yang dimainkan.
4. Penentuan lokasi masjid yang terdekat dari tempat dimana pengguna berada.
Fitur tambahan aplikasi Muslim Prayer Time adalah memberikan informasi masjid terdekat. Informasi ini berupa nama masjid dan nama jalan dimana masjid itu berada. Fitur ini tidak memberikan informasi jarak masjid dengan lokasi pengguna karena keterbatasan teknologi mobile positioning yang digunakan.
5. Komunikasi Client Server
Aplikasi Muslim Prayer Time merupakan aplikasi mobile phone yang memiliki keterbatasan memori, kapasitas penyimpanan, dan kemampuan komputasi. Karena itu tidak mungkin untuk menyimpan semua data koordinat suatu tempat dan daftar nama masjid serta lokasinya. Untuk itu, aplikasi ini mengadopsi arsitektur client server. Aplikasi di sisi klien bertugas menentukan posisi pengguna saat itu berada sedangkan aplikasi di sisi server bertugas menentukan waktu sholat berdasarkan posisi pengguna dan masjid yang terdekat dengan pengguna.
3.3.3 Batasan Perangkat Lunak
Kakas hanya dapat memberikan informasi waktu shalat ketika terdapat sinyal yang diterima oleh mobile karena untuk memperoleh waktu shalat dibutuhkan input koordinat lokasi yang didapatkan dari ID sel BTS.
3.3.4 Pemodelan Perangkat Lunak
Untuk mendapatkan gambaran yang lebih jelas mengenai perangkat lunak yang akan dibangun pada Tugas Akhir ini, dilakukan pemodelan perangkat lunak yang mencakup pemodelan fungsionalitas, pemodelan interaksi elemen dalam sistem, dan pemodelan kelas potensial. Pemodelan perangkat lunak dilakukan sebagai bagian dari aktivitas analisis dan
peracangan perangkat lunak. Mengacu pada Tabel III-1, aktivitas analisis dan perancangan perangkat lunak pada Tugas Akhir ini dilakukan secara iteratif dan incremental pada fase
inception, elaboration, dan construction. Pemodelan fungsionalitas menghasilkan diagram use case. Skenario use case dan sequence diagram dihasilkan dari pemodelan interaksi
elemen dalam sistem. Sedangkan pemodelan kelas potensial menghasilkan identifikasi paket dan kelas analisis.
3.3.4.1 Pemodelan Fungsionalitas
Diagram use case menggambarkan fitur yang dicakup perangkat lunak yang akan dikembangkan. Realisasi fitur perangkat lunak dalam bentuk diagram use case digambarkan pada Gambar III-3, sedangkan penjelasan mengenai aktor dan use case terkait serta keterhubungan antara use case dengan spesifikasi kebutuhan terdapat pada Lampiran A Tabel 2-3, Tabel 2-4, dan Tabel 2-5. Untuk setiap use case yang terdefinisi, didefinisikan pula skenario use case. Skenario use case tersebut terdapat pada LAMPIRAN A Subbab 2.3.4.
user
layanan waktu sholat
layanan masjid terdekat
clock alarm waktu sholat
mengaktifkan alarm
mematikan alarm
<<uses>>
Gambar III-3 Diagram Use Case Aplikasi
Penentuan aktor didasarkan pada tipe orang atau sistem lain yang menggunakan aplikasi. Terdapat dua aktor dalam skenario aplikasi ini yaitu user dan clock. User merupakan pengguna yang meminta layanan informasi waktu sholat atau masjid terdekat sedangkan clock adalah sistem lain yang mentrigger alarm.
Penentuan use cases didasarkan pada fungsi-fungsi yang diimplementasikan di dalam setiap subsistem. Terdapat lima use cases pada aplikasi ini yaitu layanan waktu sholat, layanan masjid terdekat, alarm waktu shalat, mengaktifkan alarm, dan mematikan alarm. Layanan waktu sholat berhubungan dengan fitur aplikasi penentuan waktu sholat sedangkan layanan masjid terdekat berhubungan dengan fitur aplikasi penentuan lokasi masjid terdekat dari tempat dimana pengguna berada. Kedua use case tersebut juga berhubungan dengan fitur penentuan cell id dan komunikasi client server antara mobile application dengan web server.
Use case alarm waktu sholat berhubungan dengan fitur alarm, penentuan waktu sholat,
penentuan cell id dan komunikasi client server. Mengaktifkan dan mematikan alarm berhubungan dengan fitur alarm waktu shalat.
3.3.4.2 Pemodelan Interaksi Elemen
Pemodelan interaksi elemen dilakukan dengan membuat sequence diagram. Sequence
diagram menggambarkan interaksi antara user dengan sistem maupun interaksi antar
elemen/objek dalam sistem.
Untuk setiap kasus normal pada skenario use case, didefinisikan sequence diagram. Sequence
diagram aplikasi “PrayLook” digambarkan secara lengkap pada Lampiran A Subbab 3.1.
Sebagai contoh, 3 sequence diagram yang digambarkan pada Gambar III-4, Gambar III-5 dan Gambar III-6.
Main <<boundary>>
DataController<<control>> XMLController<<control>> : user
WaktuSholatController<<control>> <<entity>>Coordinate
1 : layanan waktu sholat()
2 : getCellID()
3 : request waktu sholat()
4 : query koordinat() 5 6 : make XML() 7
8 : read XML()
9 : simpan cell id dan koordinatnya() 10 : get waktu sholat()
11 : tampilkan ke user()
: user Main <<boundary>> DataController<<control>> XMLController <<control>>
MasjidTerdekatController<<control>> <<entity>>Masjid
1 : layanan masjid terdekat()
2 : getCellID()
3 : request masjid terdekat()
4 : query() 5 6 : make XML() 7 8 : read XML() 9 : tampilkan ke user() dipanggil setiap detiknya selama 1 menit
Gambar III-5 Sequence diagram Layanan Masjid terdekat
: clock
Main <<boundary>>
DataController<<control>> XMLController<<control>> WaktuSholatController<<control>> <<entity>>Coordinate
1
2 : getCellID()
3 : request waktu shalat()
4 : query coordinate() 5 6 : make XML() 7
8 : readXML()
9 : simpan cell id dan koordinatnya() 10 : get waktu shalat()
11 : getTimeLeft() 12 : play alarm()
Gambar III-6 Sequence diagram Alarm
3.3.4.3 Pemodelan Kelas Potensial
Berdasarkan objek yang teridentifikasi dalam pendefinisian sequence diagram, diperoleh kelas-kelas yang terdapat pada Tabel III-6. Pada tahap analisis perangkat lunak ini, teridentifikasi 7 kelas potensial. Secara garis besar keterhubungan antar kelas dalam paket secara terperinci digambarkan pada Gambar III-7. Keterhubungan antar kelas dalam paket
secara terperinci digambarkan pada Lampiran A Gambar 3-5 dan Gambar 3-6. Tabel III-6 menggambarkan keterhubungan antar kelas dan subpaket dalam paket layananMobile dan layananServer.
Tabel III-6 Kelas Analisis Aplikasi "PrayLook"
No. Nama Kelas Jenis
Paket LayananMobile 1. Main Boundary 2. DataController Controller 3. XMLController Controller Paket LayananServer 4. WaktuSholatController Controller 5. MasjidTerdekatController Controller 6. Masjid Entity 7. Coordinate Entity System LayananMobile LayananServer
Gambar III-7 Diagram Paket Aplikasi "PrayLook"
3.4 Perancangan
Perangkat
Lunak
Berdasarkan analisis perangkat lunak yang telah dilakukan sebelumnya, dilakukan perancangan perangkat lunak yang mencakup perancangan subsistem, perancangan kelas, perancangan antarmuka, dan perancangan implementasi aplikasi. Mengacu pada Tabel III-1, perancangan perangkat lunak pada Tugas Akhir ini dilakukan secara iteratif dan incremental pada fase elaboration dan construction. Perancangan subsistem menghasilkan identifikasi subsistem dari aplikasi yang akan dibangun. Perancangan kelas menghasilkan identifikasi paket dan kelas analisis yang dilakukan pada analisis perangkat lunak. Perancangan kelas menghasilkan identifikasi kelas perancangan. Perancangan antarmuka dilakukan hanya pada aplikasi di sisi pengguna yaitu pada mobile phone. Perancangan implementasi aplikasi dilakukan untuk mengetahui node di mana aplikasi akan diimplementasikan. Perancangan implementasi aplikasi menghasilkan deployment diagram.
3.4.1 Perancangan Subsistem
Aplikasi “PrayLook” terdiri dari dua subsistem, yaitu layanan mobile dan layanan server. Pembagian aplikasi menjadi dua subsistem tidak hanya secara logic tetapi juga implementasi fisiknya terpisah, subsistem layanan mobile ditempatkan pada sebuah mobile phone dan subsistem layanan server ditempatkan pada sebuah web server.
Subsistem layanan mobile berfungsi untuk memberikan layanan informasi waktu sholat sesuai posisi pengguna sekarang dan informasi lokasi masjid terdekat yang dapat dijangkau oleh pengguna serta memberikan alarm waktu sholat. Subsistem ini juga menentukan sel ID BTS
mobile phone saat itu. Subsistem layanan server berfungsi untuk menentukan waktu sholat
berdasarkan sel id mobile phone milik pengguna dan menentukan lokasi masjid terdekat.
3.4.2 Identifikasi Kelas Perancangan
Berdasarkan kelas-kelas potensial yang diperoleh dari hasil identifikasi pada Subbab 3.3.4.3, dilakukan identifikasi ulang untuk mendapatkan kelas-kelas yang merepresentasikan sistem yang akan dibangun. Kelas-kelas yang tidak mencerminkan tanggung jawab sistem terhadap permasalahan tidak akan digunakan. Paket yang teridentifikasi pada tahap analisis serupa pada tahap perancangan karena aplikasi “PrayLook” tidak menambah atau memanfaatkan
framework lain.
Garis besar kelas perancangan aplikasi “PrayLook” terdapat pada Tabel III-7. Pada tahap perancangan ini teridentifikasi 7 kelas. Diagram kelas yang menyatakan keterhubungan kelas dalam paket layananMobile dan paket layananServer digambarkan pada Gambar III-8 dan Gambar III-9. Hasil identifikasi kelas final secara lebih detail terdapat pada Lampiran A Subbab 4.1 dan 4.2.
Tabel III-7 Kelas Perancangan Aplikasi "PrayLook"
No. Nama Kelas Perancangan Nama Kelas Analisis
Paket LayananMobile 1. PraylookApp Main 2. PraylookData DataController 3. PraylookXML XMLController Paket LayananServer 4. PrayTimeService WaktuSholatController 5. MasjidService MasjidTerdekatController 6. Masjid Masjid 7. Coordinate Coordinate
PraylookApp <<boundary>> +handle_selection() +playing() +setAlarm() +unsetAlarm() PraylookData<<control>> -cellid +shubuh +dzuhur +ashar +maghrib +isya +getCellID() +getJadwal() +setJadwal() +getDuration() PraylookXML<<control>> +parsePrayer() +parseMasjid() +appendfile()
Gambar III-8 Diagram Kelas dalam Paket LayananMobile Tahap perancangan
PrayTimeService<<control>> -cellID -Coordinate -shubuh -dzuhur -ashar -magrib -isya +getCoordinate() +MakeXML() MasjidService<<control>> -masjid -cellID +getCloserMasjid() +MakeXML() Masjid <<entity>> Coordinate<<entity>>
Gambar III-9 Diagram Kelas dalam Paket LayananServer Tahap Perancangan
3.4.3 Perancangan Representasi Persisten Kelas Entity
Dari kelas perancangan yang terdefinisi pada Tabel III-1, dibutuhkan suatu representasi persisten untuk beberapa kelas yang terdapat pada paket layananServer. Representasi persisten tersebut diwujudkan dalam bentuk tabel basis data. Suatu kelas tertentu akan dipetakan menjadi sebuah tabel basis data. Demikian pula keterhubungan antar dua kelas akan dipetakan menjadi sebuah tabel basis data. Tabel III-8 menampilkan representasi persisten kelas entity.
Tabel III-8 Representasi Persisten Kelas Entity
No Nama Tabel Atribut Tipe Data Keterangan Kelas Entity
CellIDc Integer Primary Key Placename Varchar(60) -
Latitude Float Satuan derajat
Longitude Float Satuan deraja
Altitude Float -
1. tblcoordinate
Timezone Integer -
Coordinate
ID Integer Primary Key
CellIDm Integer - Masjidname Varchar(60) - 2. tblMasjid Address Varchar(60) - Masjid 3.4.4 Perancangan Antarmuka
Gambar III-10 dan Gambar III-11 menggambarkan rancangan antarmuka aplikasi “PrayLook” untuk subsistem layananMobile. Gambar III-10 menampilkan informasi jadwal sholat dan Gambar III-11 menampilkan informasi lokasi masjid terdekat.
Gambar III-10. Informasi Jadwal Waktu Sholat
3.4.5 Deployment Diagram
Dari Gambar III-12, kedua subsistem aplikasi diimplementasikan pada node yang berbeda. Subsistem layananMobile diimplementasikan pada node Client – Mobile Phone sedangkan subsistem layananServer diimplementasikan pada node Server. Kedua node terhubung melalui HTTP.
Client - Mobile Phone HTTP Server
![Gambar III-1 Informasi Sinyal BTS [LEI05]](https://thumb-ap.123doks.com/thumbv2/123dok/4388055.3198938/10.918.261.662.165.377/gambar-iii-informasi-sinyal-bts-lei.webp)
