BAB III ANALISIS DAN PERANCANGAN

(1)

III-1

ANALISIS DAN PERANCANGAN

Pada Bab Tiga ini akan dilakukan analisis dan perancangan berdasarkan landasan teori yang telah dijelaskan pada bab sebelumnya. Analisis dimulai dari masalah dalam melakukan pembangunan aplikasi pelacakan dan penelusuran yang memiliki platform mobile Android. Selain analisis masalah juga dibahas mengenai analisis perangkat lunak yang meliputi deskripsi umum aplikasi, kebutuhan fungsionalitas, dan use case.

Kemudian akan dilanjutkan dengan bahasan mengenai perancangan yang meliputi diagram kelas, sequence, dan antarmuka. Analisis dan perancangan perangkat lunak dilakukan dengan metode berorientasi objek melalui pendekatan use case driven yang dimodelkan menggunakan standar Unified Modeling Language (UML).

3.1 Analisis Masalah

Dalam melakukan pembangunan aplikasi pelacakan & penelusuran perangkat mobile pada platform Android terdapat beberapa masalah dan faktor–faktor penting yang perlu diperhatikan. Faktor-faktor yang akan dianalisis tersebut, yaitu mengenai permasalahan penentuan lokasi perangkat mobile, permasalahan komunikasi dan konektivitas pada perangkat mobile, permasalahan keamanan aplikasi, dan permasalahan keterbatasan resource dari perangkat mobile. Hasil analisis ini akan dijadikan sebagai acuan dalam pemilihan teknologi yang akan digunakan dalam perancangan solusi.

3.1.1 Analisis Permasalahan Penentuan Lokasi

Untuk melakukan penentuan lokasi suatu perangkat mobile terdapat banyak cara, namun yang kerap digunakan adalah Cell Identification (Cell-ID) dan Global Positioning System (GPS). Pemanfaatan Cell-ID memiliki kelebihan yaitu tidak membutuhkan perangkat tambahan karena memanfaatkan fasilitas penyedia jaringan yang memungkinkan seorang pelanggan seluler untuk mengetahui posisinya terhadap Base Transceiver Station (BTS) terdekat. Namun akurasi dengan teknik Cell-ID ini sangat rendah yaitu berkisar 1-3 kilometer (km). GPS memiliki akurasi yang jauh lebih tinggi (lebih detail tentang GPS telah dibahas pada Subbab 2.3) sehingga lebih

(2)

cocok untuk diimplementasikan dalam sistem pelacakan meskipun teknik ini mengharuskan dibutuhkannya perangkat tambahan.

Oleh karena itu, dalam pembangunan perangkat lunak untuk Tugas Akhir ini diputuskan untuk mengimplementasikan metode mobile positioning menggunakan GPS dikarenakan tingkat akurasinya yang jauh lebih tinggi dibandingkan dengan Cell-ID.

3.1.2 Analisis Permasalahan Komunikasi

Perangkat lunak harus mampu melakukan komunikasi antar perangkat mobile ketika terjadi permintaan pelacakan. Untuk masalah komunikasi ini terdapat dua alternatif yaitu memanfaatkan layanan messaging Short Messaging Service (SMS) atau memanfaatkan koneksi Internet.

Alternatif pertama adalah cara yang paling praktis namun penggunaan layanan SMS untuk komunikasi ini memiliki setidaknya tiga kelemahan, yaitu: (1) SMS tidak bersifat real-time sehingga membutuhkan waktu yang lebih lama untuk terkirim, (2) data yang bisa dikirim melalui SMS terbatas 160 karakter, dan (3) biayanya relatif lebih mahal.

Tabel III-1 Perbandingan Alternatif Komunikasi

SMS Paket Data

Tidak efektif untuk pengiriman data yang panjang karena 1 SMS terbatas hanya pada 160 karakter

Efektif untuk pengiriman data yang panjang

Didukung oleh semua kelas handset Hanya didukung oleh handset kelas mid- end ke atas (mendukung

GPRS/EDGE/UMTS/3G) Praktis, tidak diperlukan instalasi

aplikasi di sisi pelacak

Pelacak harus melakukan instalasi aplikasi untuk mengakses layanan Biaya relatif lebih mahal Biaya relatif lebih murah

Alternatif berikutnya adalah dengan memanfaatkan koneksi paket data dengan Internet baik melalui GPRS/EDGE/UMTS/3G. Alternatif ini biarpun implementasinya lebih sulit namun mampu mengatasi kelemahan yang terdapat pada layanan SMS karena (1) pesan dapat dikirim secara lebih cepat karena penggunaan

(3)

socket yang persistent, (2) data yang bisa dikirim tidak terbatas 160 karakter, dan (3) biayanya relatif lebih murah. Tabel III-1 memperlihatkan perbandingan alternatif komunikasi antara penggunaan SMS dengan paket data.

Untuk komunikasi memanfaatkan paket data ini sendiri terdapat dua opsi untuk model arsitektur komunikasi, yaitu model client-server dan peer-to-peer (P2P). Untuk model client-server maka dibutuhkan sebuah server terpusat yang harus available sepanjang waktu. Hal ini dikarenakan perangkat lunak yang memanfaatkan layanan paket data akan mendapatkan IP address dinamis yang private, dimana IP address yang bersifat private & dinamis ini tidak bisa dihubungi dari pihak luar. Dengan memanfaatkan sebuah server yang menyimpan informasi maka perangkat dapat saling berkomunikasi dengan mengakses informasi yang terdapat di server. Sedangkan untuk model arsitektur P2P, perangkat akan memiliki sebuah koneksi ke server dimana seluruh traffic komunikasi akan dikirim melalui server yang bertindak hanya sebagai perantara.

Dalam pembangunan perangkat lunak diputuskan untuk mengimplementasikan baik SMS dan Internet dikarenakan masing-masing memiliki kelebihan tersendiri. Adapun model komunikasi koneksi yang dipilih adalah menggunakan arsitektur P2P.

Pemilihan P2P dikarenakan sistem ini telah didukung Android melalui API GTalk Service yang memanfaatkan eXtensible Messaging and Presence Protocol (XMPP).

Sehingga sistem akan lebih mudah untuk diimplementasikan karena tidak perlu membangun server lagi namun memanfaatkan layanan server GTalk milik Google.

Oleh karena aplikasi akan memanfaatkan layanan server GTalk maka pengguna harus memiliki akun Google untuk menggunakan aplikasi. Akun Google ini akan digunakan untuk mengakses layanan GTalk sehingga aplikasi bisa melakukan komunikasi

3.1.3 Analisis Permasalahan Keamanan

Perangkat lunak pelacakan dan penelusuran ini sangat rawan terhadap permasalahan sosial seperti penguntitan sehingga perangkat lunak harus memiliki fasilitas keamanan untuk memastikan informasi lokasi hanya bisa diakses oleh pengguna yang memiliki otoritas. Permasalahan autentikasi dapat diakomodasi melalui autentikasi password

(4)

atau filtering nomor telepon, sedangkan permasalahan kerahasiaan informasi ketika komunikasi dapat diakomodasi melalui implementasi Secure Socket Layer (SSL).

Pada proses autentikasi pelacak (pengguna) terdapat dua pilihan. Pertama dilakukan melalui password, yaitu pelacak dianggap memiliki otoritas terhadap informasi jika mengetahui password yang telah disepakati sebelumnya. Password ini sendiri akan disimpan dalam bentuk terenkripsi melalui teknik kriptografi hash. Pilihan kedua adalah melakukan proses filtering nomor telepon yaitu dengan mendaftarkan nomor telepon yang diperbolehkan untuk mengakses informasi.

Opsi pertama memiliki kelemahan terhadap kasus kebocoran password dimana jika password bocor kepada pihak yang sebenarnya tidak memiliki otoritas maka pihak tersebut dapat mengakses informasi. Sedangkan opsi kedua memiliki kelemahan jika nomor telepon tercuri oleh pihak yang tidak memiliki otoritas maka pihak tersebut dapat mengakses informasi. Sebagaimana kasus bocornya password dan pencurian perangkat mobile sering terjadi di Indonesia, maka diputuskan agar perangkat lunak mendukung kedua proses autentikasi ini dalam security profile-nya sehingga keduanya bisa saling melengkapi.

Untuk proses filtering nomor telepon sendiri terdapat dua alternatif yaitu blacklist dan whitelist.

1. Whitelist adalah daftar nomor telepon yang boleh melakukan akses informasi.

Pendekatan whitelist akan lebih baik digunakan jika sistem merupakan layanan yang diakses oleh kalangan terbatas, namun sulit jika diterapkan pada layanan yang dapat diakses publik.

2. Sebaliknya blacklist adalah daftar nomor yang TIDAK boleh mengakses informasi. Pendekatan blacklist akan lebih baik digunakan pada layanan yang bersifat publik. Berdasarkan karakteristik perangkat lunak pelacakan yang berupa layanan terbatas maka alternatif whitelist akan lebih efektif untuk digunakan.

(5)

Gambar III-1 Security Profile Perangkat Lunak

Sehingga untuk mengakses informasi dari mobile object (target) maka pelacak harus melakukan proses autentikasi terlebih dahulu dengan memasukkan password, password ini kemudian dienkripsi dengan algoritma hash yang telah didukung library Android, dan dikirimkan kepada target yang akan mencocokan password dengan password yang telah tersimpan. Jika password sama dan nomor telepon pelacak terdapat dalam daftar whitelist barulah pelacak diperbolehkan mengakses informasi lokasi. Seluruh pertukaran informasi ini dilakukan melalui SSL. Gambar III-1 menunjukkan security profile pada perangkat lunak.

3.1.4 Analisis Permasalahan Pemilihan Algoritma Kriptografi

Library Android telah mendukung berbagai algoritma kriptografi hash yang umum digunakan mulai dari Message Digest version 2 (MD2), Message Digest version 5 (MD5), Secure Hash Algorithm version 1 (SHA-1), Secure Hash Algorithm 256 bit (SHA-256), Secure Hash Algorithm 384 bit (SHA-384), hingga Secure Hash Algorithm 512 bit (SHA-512).

Secara umum, algoritma MD5 dan SHA-1 adalah yang paling sering digunakan dalam berbagai aplikasi untuk melakukan fungsi hash. Kedua algoritma ini sama-sama memiliki kelebihan dan kekurangan masing-masing. Algoritma MD5 memiliki kelebihan yaitu membutuhkan waktu komputasi yang lebih sedikit dibandingkan SHA-1. Namun MD5 juga telah terbukti lebih mudah mengalami collision dibanding SHA-1 sehingga MD5 amat tidak disarankan untuk digunakan dalam aplikasi yang membutuhkan tingkat keamanan yang critical.

(6)

Dalam pembangunan perangkat lunak akan digunakan algoritma MD5 karena algoritma ini biarpun telah terbukti dapat mengalami collision namun masih cukup aman untuk digunakan asalkan pihak lain tidak dapat mengakses data terenkripsi tersebut. Adapun SHA-1, SHA-256, SHA-384, dan SHA-512 biarpun lebih aman namun menghabiskan waktu komputasi yang lebih banyak, padahal aplikasi yang dibangun bukanlah aplikasi yang membutuhkan tingkat keamanan yang critical melainkan aplikasi mobile yang memiliki resources sangat terbatas.

Algoritma MD5 ini akan digunakan untuk menyimpan password yang akan digunakan sebagai otentikasi dalam proses pelacakan sehingga masalah sosial seperti penguntitan dapat dihindari.

3.1.5 Analisis Permasalahan Resource

Suatu perangkat mobile memiliki keterbatasan resources terutama jika dibandingkan dengan perangkat konvensional seperti komputer desktop yang menyebabkan penggunaan resource pada proses komputasi mobile harus dilakukan secara se-efisien dan se-efektif mungkin. Keterbatasan resources yang penting diperhatikan adalah seperti masalah power baterai, keterbatasan memori & proses komputasi, dan biaya komunikasi.

Untuk penghematan power baterai maka perangkat lunak yang dibangun ini tidak boleh mengandung terlalu banyak gambar atau animasi. Tampilan grafis perangkat lunak akan menggunakan tampilan yang sederhana namun tetap representatif dan user friendly. Aplikasi juga akan memanfaatkan fitur dari komponen Intent Receiver dari Android sehingga aplikasi tidak perlu terus-menerus running untuk dapat dilacak melainkan akan dijalankan oleh sistem operasi ketika ada event yang memicunya. Jadi ketika terdapat koneksi yang melakukan request pelacakan terhadap aplikasi barulah aplikasi akan dijalankan secara otomatis oleh sistem. Dengan cara ini tentu aplikasi dapat menghemat power baterai secara signifikan karena hanya perlu melakukan komputasi di saat yang diperlukan saja.

(7)

Dalam menangani keterbatasan memori maka perangkat lunak akan melakukan alokasi memori se-optimal mungkin, sedangkan untuk mengatasi keterbatasan proses komputasi maka perangkat lunak akan melakukan komputasi seminim mungkin dan mengunakan thread sesedikit mungkin. Mengenai permasalahan biaya komunikasi maka perangkat lunak akan menyediakan berbagai antarmuka untuk konektivitas jaringan, yaitu melalui SMS dan GPRS/EDGE/UMTS. Informasi yang dipertukarkan juga harus se-efisien mungkin agar dapat menekan biaya komunikasi.

3.2 Kebutuhan Perangkat Lunak

Subbab ini berisi tentang usaha memodelkan kebutuhan dari perangkat lunak. Model kebutuhan bertujuan untuk memberikan deskripsi perangkat lunak dan mendefinisikan fungsionalitasnya.

3.2.1 Deskripsi Umum Perangkat Lunak

Perangkat lunak adalah sebuah aplikasi mobile yang mendukung pelacakan dan penelusuran terhadap perangkat mobile lain. Perangkat lunak akan terdiri dari 2 buah sistem, yaitu pelacak dan target. Sistem pelacak ibaratnya sebuah client yang meminta informasi dari server dimana sistem target berperan sebagai server yang melayani request informasi tersebut.

Aplikasi mendukung pelacakan dengan mengidentifikasi lokasi perangkat mobile memanfaatkan sistem GPS. Informasi yang masih berupa koordinat ini kemudian diproses melalui data-data dari GIS Server untuk menghasilkan informasi yang lebih human-readable. Selanjutnya aplikasi menyediakan informasi lokasi ini agar dapat diakses secara remote melalui jaringan oleh aplikasi pelacakan lain. Lebih mudahnya dapat dilihat di Gambar III-2.

Sebagai contoh, ketika seorang pelacak ingin mengetahui lokasi dari sebuah perangkat mobile target maka pelacak cukup melakukan request lokasi terhadap target.

Pengiriman request dapat dilakukan melalui SMS (jika pelacak tidak memiliki aplikasi) atau paket data (internet) GPRS/EDGE/UMTS (jika telah aplikasi telah terinstall di handset pelacak). Ketika target menerima request informasi lokasi, maka

(8)

aplikasi akan akan menentukan posisi melalui sistem GPS, kemudian mengirimkan posisi ke pelacak. Pelacak kemudian menghubungi GIS Server melalui koneksi internet untuk mendapatkan informasi terkait koordinat yang telah diterima dari target. Hasil informasi lokasi ini kemudian ditampilkan kepada pengguna.

Gambar III-2 Deskripsi Umum Perangkat Lunak

3.2.2 Kebutuhan Perangkat Lunak

Tabel III-2 berisi tentang spesifikasi kebutuhan dari perangkat lunak (Software Requirement Spesification). Adapun aturan penomoran adalah sebagai berikut: kode FP untuk kebutuhan fungsional sistem pelacak; kode FT untuk kebutuhan fungsional sistem target; dan kode NF untuk kebutuhan non-fungsional sistem.

Tabel III-2 Kebutuhan Perangkat Lunak ID-SRS Deskripsi

FP-01 Pelacakan

Sistem harus mampu melakukan pelacakan yaitu melakukan request informasi lokasi dan menerima responsenya.

FP-02 Penelusuran

Sistem harus mampu melakukan penelusuran yaitu mendapatkan informasi lokasi per tiap satuan waktu secara berkala

FP-03 Peringatan Geofence

Sistem harus mampu memunculkan pesan peringatan jika target keluar dari batas (boundary) geofence yang telah ditentukan.

(9)

ID-SRS Deskripsi FP-04 Preferensi

Sistem harus memiliki fasilitas pengaturan preferensi untuk mengatur batas penelusuran, periode penelusuran, dan berbagai parameter pelacakan lainnya.

FT-01 Response Pelacakan

Sistem harus mampu mengirimkan informasi lokasi ketika terdapat request pelacakan atau penelusuran.

FT-02 Konfigurasi

Sistem harus menyediakan fasilitas untuk melakukan konfigurasi berbagai aturan untuk me-response pelacakan.

NF-01 Kemudahan Pengunaan

Sistem harus memiliki memiliki graphical user interface (GUI) yang mudah dipelajari dan mudah digunakan.

NF-02 Kehandalan Sistem

Sistem handal dengan kata lain harus mampu menyediakan service ketika dibutuhkan dimana frekuensi crash cukup rendah sehingga masih dapat ditolerir oleh pengguna.

NF-03 Keamanan Data

Sistem memiliki fitur yang mampu menjaga keamanan informasi dari pihak yang tidak memiliki otoritas

3.2.3 Diagram Use Case

Gambar III-3 berupa diagram use case untuk perangkat lunak. Deskripsi mengenai masing-masing use case dapat dilihat pada Subbab 3.2.5.

(10)

Gambar III-3 Use Case Perangkat Lunak

3.2.4 Identifikasi Aktor

Tabel III-3 berisi tentang daftar aktor dan deskripsi peran mereka masing-masing dalam perangkat lunak ini.

Tabel III-3 Definisi Aktor Perangkat Lunak

No Aktor Deskripsi

P-01 Pelacak Merupakan pengguna yang menggunakan perangkat lunak dalam mode sistem pelacak (lihat dari sudut pandang pelacak)

P-02 Target Merupakan pengguna yang menggunakan perangkat lunak dalam mode sistem target (lihat dari sudut pandang target)

P-03 Pelacak Remote Merupakan bagian dari sistem remote yang sedang melacak posisi perangkat lunak (lihat dari sudut pandang target)

(11)

No Aktor Deskripsi

S-01 Timer Merupakan bagian dari sistem operasi yang menangani pewaktuan sistem

S-02 GPS Receiver Merupakan pihak yang menyediakan informasi posisi dari target

S-03 GIS Server Merupakan pihak yang menyediakan informasi geografis suatu lokasi

S-04 Target Remote Merupakan bagian dari sistem remote yang sedang dilacak oleh perangkat lunak (lihat dari sudut pandang pelacak)

3.2.5 Identifikasi Use Case

Tabel III-4 berisi daftar use case dan deskripsi singkat masing-masing use case dalam perangkat lunak ini.

Tabel III-4 Deskripsi Use Case No Use Case Deskripsi Singkat

UC-01 Melakukan Pelacakan Aktor dapat melakukan pelacakan terhadap target remote.

UC-02 Melakukan Penelusuran

Aktor dapat melakukan penelusuran terhadap target remote.

UC-03 Mendapatkan Peringatan Geofence

Aktor bisa mendapatkan peringatan geofence jika target pelacakan keluar dari batas yang telah ditentukan ketika pengaturan preferensi.

UC-04 Mengatur Preferensi Penelusuran

Aktor dapat melakukan pengaturan preferensi penelusuran yaitu periode waktu dan batas wilayah.

UC-05 Pelacakan Otomatis Pelacakan otomatis yang dilakukan secara berkala oleh aktor untuk mendukung proses penelusuran.

UC-06 Mendapatkan Jawaban Request Pelacakan

Aktor bisa mendapatkan jawaban terhadap request pelacakan dari target remote.

UC-07 Melakukan Konfigurasi

Aktor dapat melakukan konfigurasi koneksi dan keamanan yaitu membatasi pihak-pihak yang dapat melakukan pelacakan terhadap dirinya.

3.2.6 Skenario Use Case

Subbab berikut berisi tentang skenario untuk setiap use case baik skenario utama maupun alternatif. Tabel III-5 berisi tentang skenario untuk use case melakukan penelusuran, sedangkan skenario untuk use case lain dapat dilihat pada Lampiran A.

(12)

Tabel III-5 Skenario Use Case Melakukan Penelusuran Nama Use

Case

Melakukan Penelusuran Aktor Utama Pelacak

Aktor Lain Target Remote, GIS Server

Prekondisi 1. Konfigurasi koneksi sudah dilakukan Skenario Utama (UC-02-S01): Melakukan penelusuran

Aksi Aktor Pelacak Reaksi Sistem Aksi Target Remote Aksi GIS Server 1. Memilih menu

utama

2. Menampilkan daftar menu

3. Memilih menu penelusuran

4. Meminta tujuan target penelusuran dan passwordnya.

5. Memasukkan Google ID target dan

passwordnya

6. Mengirimkan request pelacakan ke target remote melalui internet

7. Menjawab request

pelacakan 8. Menerima hasil

pelacakan berupa koordinat

9. Meminta informasi lokasi dengan koordinat tersebut dari GIS Server

10. Mengirimkan

informasi lokasi dari koordinat yang diminta 11. Menampilkan hasil

pelacakan beserta informasinya

Skenario Alternatif (UC-02-S02): Melakukan penelusuran namun terdapat pesan error.

Aksi Aktor Pelacak Reaksi Sistem Aksi Target Remote

Aksi GIS Server

7.a. Membalas

request dengan pesan error, misalnya karena salah password atau lokasi tidak tersedia.

8.a. Menerima pesan error.

9.a. Menampilkan pesan error.

Skenario Alternatif (UC-02-S03): Melakukan penelusuran namun tidak terdapat koneksi internet Aksi Aktor Pelacak Reaksi Sistem Aksi Target

Remote

Aksi GIS Server 6.a. Menampilkan pesan

(13)

pemberitahuan tidak terdapat koneksi internet.

Skenario Alternatif (UC-02-S04): Melakukan penelusuran namun tidak terdapat koneksi GTalk Aksi Aktor Pelacak Reaksi Sistem Aksi Target

Remote

Aksi GIS Server 6.b. Menampilkan pesan

pemberitahuan tidak terdapat koneksi GTalk.

Skenario Alternatif (UC-02-S05): Melakukan penelusuran namun tidak terdapat koneksi ke GIS Aksi Aktor Pelacak Reaksi Sistem Aksi Target

Remote

Aksi GIS Server 9. Meminta informasi lokasi

dengan koordinat tersebut dari GIS Server

10.a. Tidak

membalas request 11.a. Menampilkan pesan

tidak terdapat koneksi ke GIS Server

Skenario Alternatif (UC-02-S06): Melakukan penelusuran namun Target tidak membalas Aksi Aktor Pelacak Reaksi Sistem Aksi Target

Remote

Aksi GIS Server 6. Mengirimkan request

pelacakan ke target remote melalui internet

7.b. Tidak menjawab request pelacakan 8.b. Menampilkan pesan

Target Remote tidak membalas

Postkondisi Sistem menampilkan hasil penelusuran dan melakukan pelacakan otomatis.

3.2.7 Problem Domain Object Model

Gambar III-4 menyediakan pemodelan domain perangkat lunak dalam bentuk objek dan hubungan antar objek tersebut. Model ini menyediakan glossary bagi model use case.

Gambar III-4 Problem Domain Object Model Perangkat Lunak

(14)

3.3 Analisis Perangkat Lunak

Subbab ini membahas tentang model analisis dari perangkat lunak. Model analisis merealisasikan use case dengan mendistribusikan kelakuan sistem pada kelas-kelas.

Model ini akan menjadi fondasi untuk melakukan perancangan.

3.3.1 Analisis Kelas

Gambar III-5 memperlihatkan diagram kelas analisis keseluruhan sistem, sedangkan detail kelas analisis untuk masing-masing use case dapat dilihat pada Lampiran B.

Gambar III-5 Diagram Kelas Analisis Keseluruhan

Pada Tabel III-6 dapat dilihat deskripsi singkat mengenai tanggung jawab masing- masing kelas analisis dalam merealisasikan use case.

Tabel III-6 Tanggung Jawab Kelas

No Nama Tanggung Jawab

1 HalamanKonfigurasi Kelas interface yang menyediakan GUI untuk melakukan pengaturan konfigurasi.

(15)

No Nama Tanggung Jawab

2 HalamanUtama Kelas interface yang menyediakan GUI utama aplikasi.

3 KoneksiGIS Kelas interface yang menyediakan antarmuka dengan server GIS.

4 KoneksiGPS Kelas interface yang menyediakan antarmuka dengan GPS Receiver.

5 KoneksiRemote Kelas interface yang menyediakan antarmuka koneksi dengan aplikasi remote.

6 Konfigurasi Kelas entity yang menyimpan informasi konfigurasi secara persisten.

7 Pelacakan Kelas kontrol yang mengendalikan fungsi pelacakan.

8 PelacakRemote Kelas entity yang menyimpan informasi pelacak remote yang sedang melacak aplikasi.

9 Penelusuran Kelas kontrol yang mengendalikan fungsi penelusuran.

10 PengaturanKonfigurasi Kelas kontrol yang mengendalikan fungsi pengaturan konfigurasi.

11 PengaturanPreferensi Kelas kontrol yang mengendalikan fungsi pengaturan preferensi.

12 Preferensi Kelas entity yang menyimpan informasi preferensi secara persisten.

13 ResponsPelacakan Kelas kontrol yang mengendalikan cara merespons request pelacakan.

14 TargetRemote Kelas entity yang menyimpan informasi target remote yang sedang dilacak.

15 Timer Kelas interface yang menyediakan antarmuka dengan timer sistem operasi.

3.4 Perancangan Perangkat Lunak

Subbab ini membahas tentang model perancangan dari perangkat lunak. Model perancangan bertujuan untuk memperbaiki model analisis dan mengadaptasinya sesuai dengan lingkungan implementasi.

3.4.1 Perancangan Use Case

Subbab ini berisi tentang model interaksi antar objek dalam setiap use case yang dimodelkan dalam sequence diagram. Gambar III-6 memperlihatkan sequence diagram untuk use case melakukan penelusuran, sedangkan sequence diagram untuk use case lain dapat dilihat pada Lampiran C.

(16)

Gambar III-6 Sequence Diagram Use Case Melakukan Penelusuran

3.4.2 Perancangan Kelas

Gambar III-7 memperlihatkan diagram kelas perancangan untuk keseluruhan sistem, sedangkan detail kelas perancangan untuk masing-masing kelas dapat dilihat pada Lampiran D.

(17)

Gambar III-7 Diagram Kelas Perancangan Keseluruhan

3.4.3 Perancangan Antarmuka

Subbab ini berisi perancangan antarmuka aplikasi. Antarmuka aplikasi dirancang dengan tampilan sederhana agar memudahkan pengguna dalam menggunakan layanan yang disediakan namun tetap disesuaikan dengan fungsionalitas yang dibutuhkan serta memperhatikan karakteristik perangkat mobile yang memiliki tampilan layar dan navigasi terbatas.

(18)

3.4.3.1 Antarmuka Awal Aplikasi Gambar III-8 berupa antarmuka awal aplikasi.

Gambar III-8 Antarmuka Awal Aplikasi

3.4.3.2 Antarmuka Menu Utama Aplikasi

Gambar III-9 berupa antarmuka menu utama aplikasi.

Gambar III-9 Antarmuka Menu Utama Aplikasi

3.4.3.3 Antarmuka Melakukan Pelacakan

Gambar III-10 berupa antarmuka use case melakukan pelacakan.

Gambar III-10 Antarmuka Melakukan Pelacakan

3.4.3.4 Antarmuka Melakukan Penelusuran

Gambar III-11 berupa antarmuka use case melakukan penelusuran.

Gambar III-11 Antarmuka Melakukan Penelusuran