147
SISTEM PENDUKUNG KEPUTUSAN WISATA KULINER BERBASIS GIS PADA PERANGKAT ANDROID LAMAN JUDUL SKRIPSI Disusun Sebagai Salah Satu Syarat Untuk Memperoleh Gelar Sarjana Komputer pada Jurusan Ilmu Komputer / Informatika Disusun oleh: Okky Pamungkas Harrinaldy J2F 008 057

[TA2] PascaSidang Rev2

Embed Size (px)

DESCRIPTION

[TA2] PascaSidang Rev2

Citation preview

SISTEM PENDUKUNG KEPUTUSAN WISATA KULINER BERBASIS GIS PADA PERANGKAT ANDROIDLAMAN JUDUL

SKRIPSI

Disusun Sebagai Salah Satu SyaratUntuk Memperoleh Gelar Sarjana Komputerpada Jurusan Ilmu Komputer / Informatika

Disusun oleh:Okky Pamungkas HarrinaldyJ2F 008 057

JURUSAN ILMU KOMPUTER / INFORMATIKAFAKULTAS SAINS DAN MATEMATIKA UNIVERSITAS DIPONEGORO2013HALAMAN PENGESAHAN

Judul:Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android

Nama:Okky Pamungkas Harrinaldy

NIM:J2F 008 057

Telah diujikan pada sidang Tugas Akhir tanggal dan dinyatakan lulus pada tanggal

Semarang, 2013

Mengetahui,Ketua Jurusan Ilmu Komputer / Informatika

Nurdin Bahtiar, S.Si, M.TNIP. 19790720 200312 1 001Panitia Penguji Tugas AkhirKetua,

Aris Sugiharto, S.Si, M.KomNIP. 19710811 199702 1 004

HALAMAN PENGESAHAN

Judul:Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android

Nama:Okky Pamungkas Harrinaldy

NIM:J2F 008 057

Telah diujikan pada sidang Tugas Akhir pada tanggal.

Semarang, bulan 2013Pembimbing Utama,

Ragil Saputra, S.Si, M.CsNIP. 19801021 200501 1 003Pembimbing Anggota

Panji Wisnu Wirawan, S.T, M.TNIP. 19810421 200812 1 002

ABSTRAKSemarang merupakan kota yang memiliki banyak potensi pariwisata, salah satunya yaitu wisata kuliner. Sekarang ini, masyarakat masih mengalami kesulitan dalam menemukan lokasi kuliner yang sesuai dengan preferensi yang diinginkan seperti jenis makanan, harga makanan, lokasi dan fasilitas restoran. Perkembangan teknologi saat ini, informasi bisa didapatkan dimanapun dan kapan pun. Salah satunya yaitu dengan menggunakan smartphone bersistem operasi Android. Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android dapat digunakan sebagai solusi untuk menentukan lokasi kuliner berdasarkan preferensi yang diinginkan. Metode yang digunakan dalam sistem pendukung keputusan ini adalah Simple Additive Weighting. Sistem ini menggunakan bahasa pemrograman Java untuk client dan bahasa pemrograman PHP untuk administrator, dengan database management system MySQL, dan didukung dengan peta digital Google Maps API. Hasil dari Sistem Pendukung Keputusan ini adalah rangking lokasi kuliner berdasarkan preferensi yang diinginkan dan letak lokasi kuliner tersebut pada Google Maps.

Kata Kunci: Kuliner, Sistem Pendukung Keputusan, Simple Additive Weighting, GIS, Android.

ABSTRACT

Semarang is a city that has a lot of potential for tourism, one of them is a culinary tour. Today, people still have difficulty in finding suitable culinary locations base of their preferences such as type of the food, the price of food, location and facilities of the restaurant. Recent technological developments, information can be obtained wherever and whenever. One of them is by using the Android smartphone operating system. GIS-Based Culinary Decision Support System on Android device can be used as a solution to determine the location of the desired culinary by preferences. The method used in this decision support system is Simple Additive Weighting. This system uses the Java programming language for client and PHP programming language for administrators, also MySQL database management system, and supported with digital map Google Maps API . Results of this Decision Support System is rank locations based culinary preferences and the desired location of the culinary location on Google Maps.Keyword: Culinary, Decision Support System, Simple Additive Weighting, GIS, Android.

KATA PENGANTARPuji syukur penulis panjatkan kehadirat Allah SWT yang telah melimpahkan rahmat dan hidayah-Nya sehingga penulis dapat menyusun tugas akhir yang berjudul Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android sehingga dapat memperoleh gelar sarjana strata satu Jurusan Ilmu Komputer/ Informatika pada Fakultas Sains dan Matematika Universitas Diponegoro (FSM UNDIP). Dalam penyusunan tugas akhir ini, penulis mendapat bantuan dan dukungan dari banyak pihak. Atas peran sertanya dalam membantu penyelesaian tugas akhir ini, penulis ingin mengucapkan terima kasih kepada : 1) Dr. Muhammad Nur, DEA selaku Dekan FSM UNDIP.2) Nurdin Bahtiar, S.Si, M.T selaku Ketua Jurusan Ilmu Komputer / Informatika FSM UNDIP.3) Indra Waspada, S.T, M.Ti selaku Koordinator Tugas Akhir.4) Ragil Saputra, S.Si, M.Cs selaku dosen pembimbing I.5) Panji Wisnu Wirawan, S,T, M.T selaku dosen pembimbing II.

Penulis menyadari bahwa masih banyak kekurangan dalam penyusunan laporan tugas akhir ini, untuk itu penulis mohon maaf dan mengharapkan saran serta kritik yang membangun dari pembaca. Semoga laporan tugas akhir ini dapat bermanfaat bagi pengembangan ilmu dan pengetahuan, khususnya pada bidang Ilmu Komputer.

Semarang, 16 Desember 2013

Penulis

DAFTAR ISI

HalHALAMAN JUDULiHALAMAN PENGESAHANiiABSTRAKivABSTRACTvKATA PENGANTARviDAFTAR ISIviiDAFTAR GAMBARixDAFTAR TABELxiDAFTAR KODExiiBAB IPENDAHULUAN11.1.Latar Belakang11.2.Rumusan Masalah21.3.Tujuan dan Manfaat31.4.Ruang Lingkup31.5.Sistematika Penulisan3BAB IIDASAR TEORI52.1.Pengertian Sistem Informasi52.2.Pengertian Sistem Pendukung Keputusan62.3.Pengertian Sistem Informasi Geografis72.4.Konsep Mobile GIS102.5.Simple Additive Weighting Method (SAW)112.6.Sistem Operasi Android dan Arsitektur Sistemnya122.7.Konsep Dasar Orientasi Objek142.8.Unified Process152.9.Unified Modeling Language192.10.Google Maps API262.11.Object Relational Mapping272.12.1.Konsep Pemetaan Dasar272.12.2.Pemetaan Hubungan Object272.12.Database Management System MySQL29BAB IIIANALISIS DAN PERANCANGAN313.1.Definisi Kebutuhan313.1.1.Deskripsi Sistem313.1.2.Model Use Case343.1.3.Kebutuhan Non-fungsional Perangkat Lunak383.2.Analisis393.2.1.Use Case Realization Tahap Analisis393.2.2.Analysis Class423.3.Perancangan443.3.1.Use Case Realization Tahap Perancangan443.3.2.Design Class483.3.3.Perancangan Basis Data493.3.4.Perancangan Antarmuka49BAB IVIMPLEMENTASI DAN PENGUJIAN554.1.Implementasi554.1.1.Implementasi Basis Data554.1.2.Implementasi Class574.1.3.Implementasi Antarmuka584.2.Pengujian634.2.1.Lingkungan Pengujian644.2.2.Rencana Pengujian644.2.3.Pelaksanaan Pengujian654.2.4.Evaluasi Pengujian70BAB VPENUTUP715.1.Kesimpulan715.2.Saran71DAFTAR PUSTAKA72LAMPIRAN A. SEQUENCE DIAGRAM74LAMPIRAN B. IMPLEMENTASI CLASS77LAMPIRAN C. DESKRIPSI HASIL DAN UJI88

DAFTAR GAMBAR

HalGambar 2.1. Komponen dalam SPK[22]6Gambar 2.2. Komponen SIG9Gambar 2.3. Arsitektur Sistem Operasi Android [12]13Gambar 2.4. Software Development Process [9]15Gambar 2.5. Hirarki Elemen dalam Unified Process [8]16Gambar 2.6. Fase-fase dalam Unified Process [9]16Gambar 2.7. Contoh Class20Gambar 2.8. Contoh Interface20Gambar 2.9. Contoh Use Case20Gambar 2.10. Contoh Component21Gambar 2.11. Contoh Use Case Diagram23Gambar 2.12. Contoh Class Diagram24Gambar 2.13. Contoh Sequence Diagram24Gambar 2.14. Contoh Activity Diagram25Gambar 2.15. Contoh Pemetaan Dasar [1]27Gambar 2.16. Contoh Hubungan Antar Object [1]29Gambar 2.17. Hubungan dalam Relational Database [1]29Gambar 3.1 Arsitektur SPANK31Gambar 3.2. Activity Diagram Sistem32Gambar 3.3. Use Case Diagram Sistem35Gambar 3.4. Class Diagram Tahap Analisis Login40Gambar 3.5. Class Diagram Tahap Analisis Kelola Data40Gambar 3.6. Class Diagram Tahap Analisis Tentukan Preferensi Kuliner41Gambar 3.7. Class Diagram Hitung Nilai Masukan dengan Metode SAW41Gambar 3.8. Class Diagram Tahap Analisis Lihat Lokasi42Gambar 3.9. Class Diagram Tahap Perancangan Login45Gambar 3.10. Sequence Diagram Login45Gambar 3.11. Class Diagram Tahap Perancangan Kelola Data46Gambar 3.12. Class Diagram Tahap Perancangan Tentukan Preferensi Kuliner46Gambar 3.13. Class Diagram Tahap Perancangan Hitung Nilai Masukan dengan Metode SAW47Gambar 3.14. Class Diagram Tahap Perancangan Lihat Lokasi48Gambar 3.15. ORM Diagram SPANK49Gambar 3.16. Rancangan Antarmuka Tab Home SPANK50Gambar 3.17. Desain Antarmuka Login50Gambar 3.18. Desain Antarmuka Tambah Data Administrator51Gambar 3.19. Desain Antarmuka Tambah Data Makanan51Gambar 3.20. Desain Antarmuka Tambah Data Restoran52Gambar 3.21. Desain antarmuka Tentukan Preferensi Kuliner53Gambar 3.22. Desain Antarmuka Lihat Lokasi54Gambar 4.2. Tampilan tab Home SPANK58Gambar 4.3. Tampilan Halaman Login59Gambar 4.4. Tampilan Halaman Tambah Data Administrator60Gambar 4.5. Tampilan Halaman Tambah Data Makanan60Gambar 4.6. Tampilan Halaman Tambah Data Restoran61Gambar 4.7. Tampilan Antarmuka Tentukan Preferensi Kuliner62Gambar 4.8. Tampilan Antarmuka Lihat Lokasi63Gambar 4.9. Masukkan nilai pada aplikasi SPANK66Gambar 4.10. Nilai kecocokan alternatif dengan kriteria68Gambar 4.11. Nilai akhir hasil perangkingan69Gambar 4.12. Hasil perangkingan70

DAFTAR TABEL

HalTabel 2.1. Jenis-jenis Analysis Class18Tabel 2.2. Jenis-jenis Relationship21Tabel 2.3. Komponen Use Case Diagram22Tabel 2.4. Komponen Activity Diagram25Tabel 3.1. Daftar Actor Sistem34Tabel 3.2. Daftar Use Case Sistem34Tabel 3.3. Detail Use Case Login36Tabel 3.4. Detail Use Case Kelola Data36Tabel 3.5. Detail Use Case Tentukan Preferensi Kuliner37Tabel 3.6. Detail use case Hitung Nilai Masukan Dengan Metode SAW37Tabel 3.7. Detail Use Case Lihat Lokasi38Tabel 3.8. Hasil Identifikasi Analysis Class42Tabel 3.9. Daftar Tanggung Jawab dan Atribut Analysis Class43Tabel 3.10. Hasil Identifikasi Design Class48Tabel 3.11. Hasil identifikasi tabel49Tabel 4.1. Implementasi Class57Tabel 4.3. Rencana pengujian65Tabel 4.4. Konversi nilai harga66Tabel 4.5. Konversi nilai fasilitas66Tabel 4.6. Konversi nilai jarak66Tabel 4.7. Alternatif restoran67Tabel 4.8. Selisih harga dan jarak setiap alternatif67Tabel 4.9. Kecocokan alternatif dengan kriteria68

DAFTAR KODE

HalKode 4.1. Implementasi tabel administrator56Kode 4.2. Implementasi tabel group56Kode 4.3. Implementasi tabel makanan56Kode 4.4. Implementasi tabel restoran56Kode 4.5. Implementasi tabel sajian57

i

iii

PENDAHULUAN

Bab pendahuluan menyajikan mengenai latar belakang, rumusan masalah, tujuan dan manfaat, serta ruang lingkup pelaksanaan dan penulisan tugas akhir mengenai sistem pendukung keputusan wisata kuliner berbasis GIS pada perangkat android.1.1. Latar BelakangSemarang sebagai ibukota Provinsi Jawa Tengah, merupakan salah satu kota yang berkembang pesat di Indonesia. Hal itu dikarenakan perkembangan perekonomian, pendidikan dan kemajuan teknologi serta pembangunan yang berkembang pesat di kota ini. Dengan keberagaman dan keunikan potensi-potensi pariwisata yang ada dikota Semarang, tentunya hal ini menarik wisatawan-wisatawan untuk berwisata ke kota Semarang, Industri pariwisata di Jawa Tengah sendiri memiliki potensi ekonomi yang cukup tinggi per tahunnya[3]. Selain mengunjungi tempat-tempat bersejarah yang ada di Semarang, tentunya para wisatawan juga mencari tempat makan untuk memenuhi kebutuhan kuliner mereka. Sebagai kota besar yang terus berkembang, menjadikan Semarang memiliki jumlah penduduk yang cukup banyak dan terus bertambah. Dengan padatnya penduduk serta keanekaragaman suku dan ras menjadikan Semarang memiliki beragam jenis makanan atau kuliner. Banyaknya lokasi wisata kuliner yang tersebar di kota Semarang tidak semuanya dapat diketahui oleh para wisatawan, dikarenakan kurangnya informasi lokasi wisata kuliner. Informasi yang ada seperti penyebaran brosur dan peta mengenai lokasi kuliner belum bisa memberikan informasi yang lebih presentatif sebab tidak semua wisatawan dapat memiliki peta atau brosur yang disebarkan tersebut. Dengan memanfaatkan kemajuan di bidang teknologi informasi yang sekarang semakin pesat, membangun suatu aplikasi sistem pendukung keputusan dapat membantu wisatawan dalam menentukan alternatif lokasi kuliner yang sesuai dengan kriteria. Selain itu, dengan media internet yang dapat diakses dengan cepat, data lokasi wisata kuliner di kota Semarang dapat diinformasikan dengan cepat, tepat dan akurat. Selain itu informasi tersebut dapat digabungkan dengan pemetaan dimana lokasi wisata kuliner itu berada. Dengan demikian informasi yang diperoleh bukan hanya textual saja tetapi juga dalam bentuk spasial atau peta yang interaktif.Dengan pesatnya perkembangan teknologi komunikasi nirkabel, SIG desktop yang konvensional memiliki kecenderungan tren yang jelas terhadap pengembangan komputasi mobile. Mobile GIS lebih banyak digunakan dalam semua jenis kegiatan. Mobile GIS adalah turunan dari GIS dan perangkat mobile, seperti PDA. Mobile GIS sendiri memiliki keuntungan dari SIG desktop serta kenyamanan yang dimiliki perangkat mobile. Hal ini sangat berguna untuk memenuhi kebutuhan aplikasi untuk mendapatkan geo-information untuk apa saja, siapa saja, di mana saja serta kapan saja. Ada banyak produk mobile GIS baik mengenai penelitian maupun komersial di seluruh dunia[23]. Antara lain Mobile GIS Pada Navigasi Jalan Menggunakan PDA Pada Kabupaten Sleman, Sistem Informasi Geografis Objek Pariwisata Pada Kabupaten Banyumas Berbasis Mobile. Sedangkan produk komersialnya antara lain aplikasi yang sudah terdaftar di Google Play Store, seperti Makan di mana, Toresto, dan lainnya. Sedangkan untuk aplikasi pendukung keputusan berbasis mobile sendiri masih jarang ditemukan baik di internet maupun yang sudah terdaftar di Google Play Store.Dengan memperhatikan fakta tersebut, permasalahan yang dihadapi oleh wisatawan dapat diatasi dengan memanfaatkan fitur yang ada di perangkat mobile. Salah satunya yaitu Google Maps pada sistem operasi Android yang telah terintegrasi di dalamnya. Yang kemudian dapat dibangun suatu sistem pendukung keputusan berbasis GIS yang dapat memberikan informasi lokasi wisata kuliner kepada masyarakat secara efektif dan efisien. Sehingga dengan dibangunnya sistem pendukung keputusan wisata kuliner berbasis GIS pada perangkat Android ini diharapkan dapat mengoptimalkan pelayanan pariwisata di kota Semarang serta membantu masyarakat dalam memperoleh informasi berbagai lokasi wisata kuliner di wilayah kota Semarang.1.2. Rumusan MasalahBerdasarkan pada latar belakang dapat dirumuskan permasalahan yang dapat diambil yaitu bagaimana membangun Sistem Pendukung Keputusan Wisata Kuliner Berbasia GIS pada Perangkat Android.1.3. Tujuan dan ManfaatTujuan yang ingin dicapai dari penelitian tugas akhir ini adalah menghasilkan aplikasi Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android.Adapun manfaat yang diharapkan dari penelitian tugas akhir ini adalah dapat membantu wisatawan dalam menentukan tujuan wisata kuliner berdasarkan kriteria yang dipilih, serta dapat digunakan sebagai media promosi pariwisata dan alat pendukung program pemerintah untuk memberikan kemudahan informasi kepada wisatawan.1.4. Ruang LingkupRuang lingkup pada pengembangan sistem pendukung keputusan wisata kuliner berbasis GIS pada perangkat Android adalah sebagai berikut :1. Pengembangan menggunakan program Eclipse IDE dengan bahasa pemrograman Java.2. Sistem ini menggunakan Google Maps API dalam menggambarkan peta.3. Sistem ini hanya dapat melakukan perhitungan berdasarkan alternatif makanan yang sejenis.4. Sistem ini melakukan perhitungan alternatif terbaik dari beberapa kriteria yaitu, harga, fasilitas (meeting room, AC, wifi, toilet, mushola, parkir, musik), dan jarak berdasarkan jenis makanan yang diinginkan.5. Keluaran sistem berupa list view rangking lokasi kuliner berdasarkan kriteria yang telah dihitung menggunakan metode SAW, deskripsi lokasi tujuan, dan direction menuju lokasi tujuan.6. Bentuk implementasi menggunakan emulator Android atau virtual device, maupun device sesungguhnya.7. Implementasi pada device sesungguhnya menggunakan device Android dengan operating system (OS) Gingerbread atau Android versi 2.38. Metode pengembangan perangkat lunak menggunakan unified process.1.5. Sistematika PenulisanSistematika penulisan yang digunakan dalam tugas akhir ini terbagi dalam beberapa pokok bahasan, yaitu:BAB IPENDAHULUANBab ini berisi latar belakang, perumusan masalah, tujuan dan manfaat, ruang lingkup, dan sistematika penulisan dalam pembuatan tugas akhir.BAB IIDASAR TEORIBab ini menjelaskan mengenai teori-teori yang mendukung dalam pengembangan Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android.BAB IIIDEFINISI KEBUTUHAN, ANALISIS, DAN PERANCANGANBab ini membahas proses pengembangan perangkat lunak dan hasil yang didapatkan pada tahap definisi kebutuhan, analisis, dan perancangan.BAB IVIMPLEMENTASI DAN PENGUJIAN Bab ini membahas proses pengembangan perangkat lunak dan hasil yang didapat pada tahap implementasi. Bab ini juga berisi rincian pengujian perangkat lunak yang dibangun dengan metode black box.BAB VPENUTUPBab ini berisi kesimpulan yang diambil berkaitan dengan perangkat lunak yang dikembangkan dan saran-saran untuk pengembangan perangkat lunak lebih lanjut.

DASAR TEORI

Dalam bab ini disajikan dasar teori yang berhubungan dengan topik tugas akhir. Dasar teori yang digunakan dalam penyusunan tugas akhir ini meliputi pengertian sistem informasi, pengertian sistem pendukung keputusan, pengertian sistem informasi geografis, konsep mobile GIS, SAW, sistem operasi Android, konsep dasar orientasi objek, unified process, unified modeling language (UML), Google Maps API, Object Relational Mapping, dan database management system MySQL.2.1. Pengertian Sistem InformasiSistem dapat didefinisikan sebagai kumpulan dari komponen-komponen atau prosedur-prosedur yang saling berhubungan satu dengan yang lainnya membentuk satu kesatuan untuk mencapai tujuan tertentu. Sedangkan informasi adalah data yang diolah menjadi suatu bentuk yang berguna bagi pemakainya. Informasi harus relevan, tepat waktu, dan akurat untuk menjadikannya berguna. Sistem informasi mempunyai enam komponen. Keenam komponen sistem informasi tersebut adalah sebagai berikut:1. InputMerupakan data yang masuk ke dalam sistem informasi. Input yang masuk ke dalam sistem informasi dapat langsung diolah menjadi informasi atau jika belum dibutuhkan sekarang dapat disimpan ke dalam basis data terlebih dahulu.2. OutputBerupa informasi yang berguna bagi pemakainya. Output dari sistem informasi dibuat dengan menggunakan data yang ada di basis data dan diproses menggunakan model tertentu.3. Basis dataKumpulan dari data yang saling berhubungan satu dengan yang lainnya, tersimpan di perangkat keras komputer dan digunakan perangkat lunak untuk memanipulasinya.

4. ModelDapat berupa model logika yang menunjukkan suatu proses perbandingan logika atau model matematik yang menunjukkan proses perhitungan matematika.5. TeknologiMembantu mempercepat sistem informasi dalam pengolahan datanya, agar dapat menghasilkan informasi yang tepat waktu.6. KontrolDigunakan untuk menjamin bahwa informasi yang dihasilkan oleh sistem informasi merupakan informasi yang akurat [10].2.2. Pengertian Sistem Pendukung KeputusanSistem Pendukung Keputusan (SPK) adalah sistem berbasis komputer yang terdiri dari tiga komponen yang saling berinteraksi antara lain [22]:1. Sistem bahasa yaitu mekanisme untuk memberikan komunikasi antara pengguna dan komponen SPK lain. 2. Sistem pengetahuan yaitu repositori pengetahuan domain masalah yang ada pada SPK, sebagai data atau sebagai prosedur. 3. Sistem pemrosesan masalah yaitu hubungan antara dua komponen lainnya, terdiri dari satu atau lebih kapabilitas manipulasi masalah umum yang diperlukan untuk pengambilan keputusan.Komponen dalam sistem pendukung keputusan terlihat pada gambar 2.1

Gambar 2.1. Komponen dalam SPK[22]Berikut merupakan penjelasan dari masing-masing komponen yang ada pada gambar 2.1:1. Subsistem manajemen dataMeliputi basis data yang mengandung data yang relevan dengan keadaan yang ada dan dikelola oleh sebuah sistem yang dikenal sebagai database management system (DBMS). 2. Subsistem manajemen modelMerupakan sebuah paket perangkat lunak yang berisi model-model finansial, statistik, management science, atau model kuantitatif yang lain yang menyediakan kemampuan analisis sistem dan management software yang terkait. 3. Subsistem manajemen pengetahuan (knowledge) Merupakan subsistem yang mampu mendukung subsistem yang lain atau berlaku sebagai sebuah komponen yang berdiri sendiri (independen). 4. Subsistem antarmuka pengguna (user interface)Merupakan media tempat komunikasi antara pengguna dan sistem pendukung keputusan serta tempat pengguna memberikan perintah kepada sistem pendukung keputusan.2.3. Pengertian Sistem Informasi GeografisMenurut ESRI (Environmental System Research Institute), Sistem Informasi Geografis (GIS) atau Geographic Information System (GIS) adalah kumpulan yang terorganisir dari perangkat keras komputer, perangkat lunak, data geografis dan personil yang dirancang secara efisien untuk memperoleh, menyimpan, meng-update, memanipulasi, menganalisis, dan menampilkan semua bentuk informasi yang bereferensi geografi [16]. Sistem Informasi Geografis yang kemudian disebut dengan SIG, pertama kali dikenal pada awal tahun 1980 dan mulai berkembang pesat sekitar tahun 1990, seiring dengan perkembangan perangkat komputer, baik perangkat lunak (software) maupun perangkat keras (hardware).Pada dasarnya, istilah sistem informasi geografis merupakan gabungan dari tiga unsur pokok: sistem, informasi, dan geografis. Melihat ketiga unsur pokok tersebut, maka jelas SIG merupakan salah satu sistem informasi dan SIG merupakan suatu sistem yang menekankan pada unsur "Informasi Geografis". Pada intinya SIG adalah sebuah sistem yang digunakan untuk melakukan pengelolaan, penyimpanan, pemrosesan, analisis, dan penayangan data yang terkait dengan permukaan bumi. Agar sistem tersebut dapat beroperasi, dibutuhkan perangkat keras dan perangkat lunak serta manusia untuk mengoperasikannya. Terdapat beberapa komponen dari SIG, yaitu [7]:1. User (Pengguna)Teknologi SIG membutuhkan pengguna dalam menjalankan, mengelola, dan membangun perencanaan sistem yang dapat diaplikasikan dalam kehidupan nyata. Kategori user dalam SIG dapat dibagi menjadi beberapa kategori yaitu operator, analis, pengembang atau programmer, database administrator maupun stakeholder.2. AplikasiMerupakan kumpulan dari prosedur-prosedur yang digunakan untuk mengolah data menjadi informasi. Misalnya penjumlahan, rotasi, query, overlay, join table, dan sebagainya.3. DataData yang digunakan dalam SIG dapat berupa data spasial dan data atribut. Data spasial ini merupakan data representasi fenomena permukaan bumi yang memiliki koordinat lazim berupa peta, foto udara, satelit, dan sebagainya atau hasil dari interpretasi data tersebut. Sedangkan data atribut merupakan data yang memiliki informasi fitur spasial, misalnya data nama dan panjang jalan, catatan survey, data statistik lainnya. Kumpulan data dalam jumlah besar dapat disusun menjadi sebuah basis data. Jadi dalam SIG juga dikenal basis data yang biasa disebut basis data spasial.4. Perangkat LunakElemen yang harus terdapat dalam komponen perangkat lunak SIG adalah :a) Tools untuk melakukan input dan pengolahan data geografis.b) Sistem Manajemen Basis Data (Database Management System).c) Tools untuk mendukung proses query, analisis, dan visualisasi data geografis.d) Graphical User Interface (GUI) untuk memudahkan pengguna SIG.

5. Perangkat KerasSIG membutuhkan pernagkat keras komputer untuk penyimpanan dan pemrosesan data. SIG membutuhkan spesifikasi perangkat keras yang lebih tinggi dibandingkan dengan sistem informasi lainnya. Perangkat keras SIG berupa seperangkat komputer dengan spesifikasi yang sesuai untuk menjalankan program SIG, serta perangkat penunjang yang lain seperti scanner, plotter, printer. Untuk melakukan proses analisis data geografis dibutuhkan processor yang cepat dan memory yang cukup besar, graphics card dan harddisk, dengan spesifikasi yang tinggi untuk kualitas gambar yang dihasilkan dan kemampuan penyimpanannya.Komponen-komponen SIG tersebut digambarkan pada gambar 2.2.

Gambar 2.2. Komponen SIGDalam SIG model data yang akan digunakan dari bentuk dunia nyata harus diimplementasikan ke dalam basis data. Data ini dimasukkan ke dalam komputer yang kemudian memanipulasi objek dasar yang memiliki atribut geometri (entity spasial/entity geografis) [15]. Hingga saat ini, secara umum, persepsi manusia mengenai bentuk representasi entity spasial adalah konsep raster dan vektor, sehingga untuk menyajikan entity spasial digunakan dua model data yakni :1. Model Data Raster Model data raster menampilkan, menempatkan, dan menyimpan data spasial dengan menggunakan struktur matriks atau piksel-piksel yang membentuk grid. Akurasi model data ini sangat bergantung pada resolusi atau ukuran pikselnya (sel grid) di permukaan bumi. Entity spasial raster disimpan di dalam layers yang secara fungsionalitas direlasikan dengan unsur-unsur petanya. Model data raster memberikan informasi spasial apa yang terjadi dimana saja dalam bentuk gambaran yang digeneralisir.2. Model Data Vektor Model data vektor menampilkan, menempatkan, dan menyimpan data spasial dengan menggunakan titik-titik, garis-garis atau kurva, atau poligon beserta atribut-atributnya. Bentuk-bentuk dasar representasi data spasial ini, di dalam sistem model data vektor, didefinisikan oleh sistem koodinat kartesian dua dimensi (x,y). Pada model data vektor terdapat tiga entity yaitu :a) Entitas TitikEntitas titik adalah representasi grafis yang paling sederhana untuk suatu objek. Representasi ini tidak memiliki dimensi tetapi dapat diidentifikasi di atas peta dan dapat ditampilkan pada layar monitor dengan menggunakan simbol-simbol.b) Entitas GarisEntitas garis adalah bentuk linier yang akan menghubungkan paling sedikit dua titik dan digunakan untuk mempresentasikan obyek-obyek dua dimensi. Obyek atau entitas yang dapat direpresentasikan dengan garis antara lain jalan, sungai atau saluran air.c) Entitas PoligonEntitas poligon digunakan untuk merepresentasikan obyek-obyek dua dimensi seperti pulau atau wilayah administrasi. Satu poligon paling sedikit dibatasi oleh tiga garis di antara tiga titik yang saling bertemu membentuk bidang. Poligon mempunyai sifat spasial luas, terisolasi atau terkoneksi dengan yang lain, bertakuk (intended), dan overlapping2.4. Konsep Mobile GISMobile GIS (Geographic Information System) merupakan integrasi antara tiga teknologi, yaitu perangkat lunak GIS, teknologi Global Positioning System (GPS), dan mobile. Teknologi tersebut membuat basis data yang dapat diakses oleh personil di lapangan secara langsung di segala tempat dan waktu.Mobile GIS adalah perpaduan dari teknologi GIS, Mobile hardware dengan perangkat lunaknya, Global Positioniong System (GPS) dan komunikasi wireless untuk akses ke internet GIS. Mobile GIS menawarkan fleksibilitas yang besar, memungkinkan pengguna memperoleh hasil secara cepat sesuai dengan kebutuhan mereka [21].2.5. Simple Additive Weighting Method (SAW)Metode SAW sering juga dikenal dengan istilah metode penjumlahan terbobot. Konsep dasar metode SAW adalah mencari penjumlahan terbobot dari rating kinerja pada setiap alternatif pada semua atribut. Metode SAW membutuhkan proses normalisasi matriks keputusan (X) ke suatu skala yang dapat diperbandingkan dengan semua rating alternatif yang ada.[11]Metode ini merupakan metode yang paling dikenal dan paling banyak digunakan orang dalam menghadapi situasi MADM (multiple attribute decision making). Metode ini mengharuskan pembuat keputusan menentukan bobot bagi setiap atribut. Skor total untuk sebuah alternatif diperoleh dengan menjumlahkan seluruh hasil perkalian antara rating dan bobot tiap atribut. Rating tiap atribut haruslah bebas dimensi yang artinya telah melewati proses normalisasi sebelumnya.Langkah Penyelesaian SAW :1. Menentukan kriteria-kriteria yang akan dijadikan acuan dalam pengambilan keputusan, yaitu Cj2. Menentukan rating kecocokan setiap alternatif pada setiap kriteria3. Membuat matriks keputusan berdasarkan kriteria (Cj), kemudian melakukan normalisasi matriks berdasarkan persamaan yang disesuaikan dengan jenis atribut (atribut keuntungan ataupun atribut biaya) sehingga diperoleh matriks ternormalisasi R.4. Hasil akhir diperoleh dari proses perankingan yaitu penjumlahan dari perkalian matriks ternormalisasi R dengan vektor bobot (w) sehingga diperoleh nilai terbesar yang dipilih sebagai alternatif terbaik (Ai) sebagai solusi.Formula untuk melakukan normalisasi tersebut adalah sebagai berikut:

.......................(2.1)

dengan : rij adalah rating kinerja ternormalisasi dari alternatif Ai pada atribut Cj i=1,2,,m dan j=1,2,,n (m dan n merupakan banyaknya kriteria dan alternatif) xij adalah nilai rating kecocokan pada Ai dan Cj.Nilai preferensi untuk setiap alternatif (Vi) diberikan sebagai berikut:

..................................................................................(2.2)

dengan : rij adalah rating kinerja ternormalisasi dari alternatif Ai pada atribut Cj wj adalah bobot dari masing masing kriteria.Nilai Vi yang lebih besar mengindikasikan bahwa alternatif Ai lebih terpilih.2.6. Sistem Operasi Android dan Arsitektur SistemnyaAndroid adalah sebuah sistem operasi untuk perangkat mobile yang menyertakan middleware (virtual machine) dan sejumlah aplikasi utama yang di Release oleh Google [2]. Android menawarkan sebuah lingkungan yang berbeda untuk pengembang. Setiap aplikasi memiliki tingkatan yang sama. Android tidak membedakan antara aplikasi inti dengan aplikasi pihak ketiga. API yang disediakan menawarkan akses ke hardware, maupun data-data ponsel sekaligus, atau data sistem sendiri. Bahkan, pengguna dapat menghapus aplikasi inti dan menggantinya dengan aplikasi pihak ketiga.Tujuan sistem operasi ini adalah untuk menyediakan platform yang terbuka, yang memudahkan orang mengakses internet menggunakan telepon seluler. Android juga dirancang untuk memudahkan pengembang aplikasi membuat aplikasi dengan batasan yang minim sehingga kreativitas pengembang menjadi lebih berkembang [2].Sistem operasi Android ini sejak mulai diluncurkan pada 23 September 2008 telah mengalami banyak penambahan fitur baru dan perbaikan terhadap kekurangan dari versi sebelumnya. Sampai saat ini tercatat sudah ada 10 versi utama dari sistem operasi Android yang diumumkan.Secara garis besar arsitektur Android terlihat pada gambar 2.3.

Gambar 2.3. Arsitektur Sistem Operasi Android [12]Berikut adalah penjelasan dari masing-masing layer pada gambar 2.3 :1) Application dan WidgetsApplication dan Widgets merupakan layer yang berhubungan dengan aplikasi, dimana aplikasi didownload kemudian melakukan instalasi dan menjalankan aplikasi tersebut. 2) Applications FrameworksPada layer ini para pembuat aplikasi melakukan pengembangan atau pembuatan aplikasi yang akan dijalankan oleh sistem operasi Android.3) LibrariesLibraries merupakan kode yang dapat digunakan oleh komponen atau program lain, para pembuat aplikasi mengakses libraries untuk menjalankan aplikasinya.4) Android RuntimeAndroid Runtime merupakan layer yang membuat aplikasi Android dapat dijalankan dimana dalam prosesnya menggunakan implementasi Linux. 5) Linux KernelLayer inti dari sistem operasi dari Android itu berada. Berisi file-file system yang mengatur sistem processing, memory, resource, drivers, dan sistem operasi Android lainnya [12].2.7. Konsep Dasar Orientasi ObjekSecara spesifik, pengertian berorientasi objek berarti bahwa perangkat lunak diorganisasikan sebagai kumpulan dari objek tertentu yang memiliki struktur data dan perilakunya. Objek merupakan suatu kesatuan komponen dan struktur yang didalamnya berisi atribut yang selanjutnya dinamakan dengan member dan method yang merupakan kumpulan fungsional dari suatu objek [20]. Contohnya adalah objek mobil. Objek mobil ini mempunyai method berupa maju, mundur, jalan, berhenti, dan berputar. Dengan demikian dapat dikatakan bahwa objek mempunyai sifat-sifat, yaitu :a. Member atau sering juga disebut dengan atribut yang menjelaskan variabel, parameter atau keadaan (state) dari suatu objek, misalkan pada objek mobil terdapat member berupa roda, kemudi, kursi, mesin dan sebagainya [20].b. Method atau sering juga disebut dengan behavior yang menjelaskan perilaku, kegiatan atau kerja dari suatu objek, misalkan pada objek mobil terdapat method maju, mundur, dan berhenti [20]. Dengan kata lain behavior merepresentasikan aktivitas objek yang terlihat [5].

Pengembangan berorientasi objek merupakan cara berpikir baru tentang perangkat lunak berdasarkan abstraksi yang terdapat dalam dunia nyata [19]. Fokus utama pada metodologi pengembangan berorientasi objek ialah dengan melihat suatu sistem teridiri dari objek yang saling berhubungan. Tiga karakteristik utama pada metodologi ini yaitu :1. Encapsulation (Pengkapsulan)Encapsulation (pengkapsulan) merupakan dasar untuk pembatasan ruang lingkup program terhadap data yang diproses. Data dan prosedur atau fungsi dikemas bersama-sama dalam suatu objek, sehingga prosedur atau fungsi dari luar tidak dapat mengaksesnya. Data terlindung dari prosedur atau objek lain kecuali prosedur yang berada dalam objek itu sendiri. Salah satu contoh dari encapsulation antara lain ketika pembentukan kelas [19].2. Inheritance (Pewarisan)Inheritance (pewarisan) merupakan konsep yang menyatakan bahwa anak dari objek akan mewarisi data atau atribut dan method dari induknya langsung. Atribut dan method dari objek induk diturunkan kepada anak objek, demikian seterusnya [19]. 3. Polymorphism (Polymorfisme)Polymorphism (polimorfisme) yaitu konsep yang menyatakan bahwa sesuatu yang sama dapat mempunyai bentuk dan perilaku yang berbeda. Atau dengan kata lain dapat menggunakan variabel dalam program untuk mengaplikasikan objek untuk memanggil method yang berbeda [19].2.8. Unified ProcessUnified Software Development Process atau biasa disebut sebagai Unified Process merupakan suatu proses pengembangan perangkat lunak [9]. Dalam hal ini perlu dipahami bahwa proses pengembangan perangkat lunak sesungguhnya merupakan aktivitas-aktivitas yang diperlukan untuk menerjemahkan kebutuhan pengguna menjadi sebuah sistem perangkat lunak seperti dijelaskan Gambar 2.4 [9].

Gambar 2.4. Software Development Process [9]

Unified Process merupakan proses pengembangan perangkat lunak yang berbasiskan komponen (component based software engineering), yang berarti sistem perangkat lunak yang dihasilkan kelak akan terdiri atas komponen-komponen perangkat lunak yang saling terhubung melalui antarmuka yang terdefinisi dengan baik. Dalam hal ini Unified Process menggunakan Unified Modelling Language (UML) sebagai kakas bantu utama analisis dan perancangan sistem perangkat lunak [13]. Daur hidup (life cycle) unified process terdiri atas 4 fase yaitu inception, elaboration, construction, dan transition. Masing-masing fase dapat memiliki satu atau lebih iterasi dan masing-masing iterasi mengeksekusi 5 core workflow yaitu requirement, analysis, design, implementation, dan test. Pada akhirnya masing-masing workflow akan terdiri dari aktivitas-aktivitas yang lebih spesifik. Hirarki elemen dalam Unified Process [8] dapat dilihat pada Gambar 2.5.Unified Process merupakan proses pengembangan perangkat lunak yang terdiri dari 2 dimensi yaitu dimensi horizontal dan dimensi vertikal [20] seperti terlihat pada Gambar 2.6. Dimensi horizontal merepresentasikan waktu dan menunjukkan daur hidup proses. Pada dimensi ini dideskripsikan 4 fase di Unified Process dan iterasi-iterasi yang ada pada masing-masing fase. Dimensi yang lain adalah dimensi vertikal yang merepresentasikan konten dan menunjukkan core workflow yang dijalankan pada masing-masing iterasi.

Gambar 2.5. Hirarki Elemen dalam Unified Process [8]

Gambar 2.6. Fase-fase dalam Unified Process [9]Empat fase yang yang ada dalam Unified Process adalah sebagai berikut:1) Inception Inception adalah tahapan pertama dari proses yaitu dengan mendefinisikan lingkup proyek dan mengembangkan bisnis proses untuk sistem. Selain itu tujuan dari fase ini adalah menangkap kebutuhan yang esensial, mengetahui bisnis proses, menetapkan kemungkinan-kemungkian, serta mengidentifikasi resiko-resiko kritis.2) ElaborationElaboration merupakan tahap kedua dari proses, ketika kebutuhan fungsional dan arsitektur dari sistem didefinisikan. Tujuan dari fase elaboration adalah menciptakan arsitektur sistem yang benar-benar akan dieksekusi. Sehingga arsitektur sistem tidak hanya sekedar prototype sistem tetapi sudah menjadi gambaran sistem yang akan dikembangkan. 3) Construction Construction adalah fase ketiga dari proses yang pada intinya adalah membangun produk yang akan dihasilkan dalam proyek. Tujuan dari fase construction adalah melengkapi semua requirement, analysis dan design serta mengembangkan garis besar arsitektur yang didapat dari fase sebelumnya menjadi final system. 4) TransitionTransition adalah fase keempat dari proses, ketika perangkat lunak tersebut dipindahkan ke lingkungan pengguna. Tujuan utama dari fase transition adalah menguji perangkat lunak terakhir yang akan diserahterimakan kepada pengguna. Pada fase ini juga diharapkan user manual dan dokumentasi telah selesai dikerjakan [4].

Seperti dijelaskan, masing-masing fase yang ada akan mengeksekusi 5 core workflow. Sedangkan 5 core workflow yang ada dalam Unified Process adalah sebagai berikut :1) Requirement Requirements atau definisi kebutuhan memiliki tujuan yang penting, yaitu untuk mengarahkan pembangunan ke arah sistem yang benar [9]. Pada core workflow ini kebutuhan-kebutuhan pengguna dikumpulkan dan kemudian mentransformasikan ke dalam sebuah deskripsi sistem yang jelas dan lengkap. Selanjutnya pada core workflow requirements sistem direpresentasikan ke dalam use case. Tahapan ini menghasilkan use case model yang terdiri atas use case, actor dan artifact lain seperti prototipe antarmuka serta kebutuhan nonfungsional [8]. Diagram UML yang digunakan untuk menggambarkan Use Case Model adalah Use Case Diagram.2) AnalysisTujuan core workflow ini adalah untuk merestrukturisasi kebutuhan yang telah diidentifikasi dalam core workflow sebelumnya. Core workflow analisis menghasilkan model analisis yaitu use case realization dan analysis class. Pada alur kerja ini dilakukan identifikasi class dan kolaborasi [8]. Stereotype dari analysis class adalah boundary class, control class, dan entity class. Penjelasan dari masing-masing analysis class dapat dilihat pada Tabel 2.1.

Tabel 2.1. Jenis-jenis Analysis ClassNo.JenisDeskripsiGambar

1.EntityEntity class mewakili data yang cenderung ada selama periode waktu, konsep penting dalam sistem, dan unsur penting dalam sistem.

2. BoundaryBoundary class digunakan untuk memodelkan interaksi sistem dengan actor.

3.ControlControl class digunakan untuk mengkoordinasikan interaksi antara actor (melalui boundary class) dengan data di entity class.

3) DesignCore workflow design akan menghasilkan rancangan rinci dari sistem yang akan diimplementasikan pada core workflow berikutnya [8]. Produk utama yang dihasilkan pada core workflow design adalah design model yang meliputi design class dan use case realization tahap design. Selain itu juga dihasilkan class diagram untuk menggambarkan hubungan antar class di dalam sistem dan sequence diagram untuk mendeskripsikan perilaku dinamis dari class. Pada core workflow design juga dibuat database design yang akan digunakan sebagai tempat penyimpanan data.4) ImplementationPada core workflow ini dilakukan implementasi dari hasil pada alur kerja design [8]. Core workflow implementasi adalah tahap yang mengkonversi sistem yang telah dirancang ke dalam sebuah bahasa yang dimengerti komputer. Kemudian komputer akan menjalankan fungsi-fungsi yang telah didefinisikan sehingga mampu memberikan layanan-layanan kepada penggunanya.5) TestCore workflow test menggambarkan kegiatan yang dilakukan untuk menguji perangkat lunak untuk memastikan bahwa perangkat lunak yang dikembangkan telah memenuhi persyaratan kebutuhan pengguna [8]. Pengujian menggunakan metode black box. Pengujian black box berfokus pada persyaratan fungsional perangkat lunak. Pengujian ini memungkinkan analis sistem memperoleh kumpulan kondisi input yang akan mengerjakan seluruh keperluan fungsional program.2.9. Unified Modeling LanguageUnified Modeling Language (UML) adalah bahasa pemodelan visual yang digunakan untuk menentukan, menggambarkan, membangun dan mendokumentasikan artefak dari suatu perangkat lunak [5]. UML menangkap keputusan dan pemahaman mengenai sistem yang akan dibangun. UML dapat digunakan pada semua metode pengembangan, tahap daur hidup, domain aplikasi dan media. UML saat ini banyak digunakan untuk mendukung proses pengembangan perangkat lunak berorientasi objek [17].Di dalam UML terdapat 3 kosakata yang meliputi 3 jenis building blocks, yaitu :1) Things2) Relationships3) Diagrams

Things merupakan abstraksi paling utama dalam UML. Terdapat 4 jenis things dalam UML, yaitu : Structural things, Behavioral things, Grouping things, Annotational things.1) Structural thingsStructural things adalah kata benda dari model-model UML. Ini adalah unsur statis dari model yang mewakili unsur-unsur baik yang konseptual maupun fisik. Biasa disebut sebagai classifier. Contoh dari structural things adalah sebagai berikut :a) ClassClass adalah deskripsi dari sekumpulan objek yang berbagi atribut, operasi, dan hubungan yang sama. Contoh dari class dapat dilihat pada Gambar 2.7.

Gambar 2.7. Contoh Classb) InterfaceInterface adalah kumpulan operasi yang menentukan pelayanan class. Sebuah interface menggambarkan perilaku eksternal yang tampak dari class. Interface akan mendefinisikan spesifikasi operasi tetapi tidak pernah ada implementasi operasi. Contoh dari interface [5] dapat dilihat pada Gambar 2.8.

Gambar 2.8. Contoh Interfacec) Use CaseUse case merupakan deskripsi urutan tindakan yang dilakukan sistem yang berpengaruh kepada actor dari sistem. Sebuah use case digunakan untuk menstrukturkan perilaku dari sistem. Contoh dari use case dapat dilihat pada Gambar 2.9.

Gambar 2.9. Contoh Use Cased) ComponentKomponen adalah bagian modular dari sistem yang digunakan untuk menyembunyikan implementasi di belakang satu set antarmuka eksternal [5]. Contoh dari component dapat dilihat pada Gambar 2.10.

Gambar 2.10. Contoh Component2) Behavioral thingsBehavioral things adalah bagian dinamis dari model UML. Behavioral things dibagi menjadi 3 yaitu interaction, state machine, dan activity. Interaction adalah perilaku yang terdiri dari serangkaian pesan yang dipertukarkan antara sekumpulan objek dalam konteks tertentu untuk mencapai tujuan tertentu. State machine adalah perilaku yang menentukan keadaan-keadaan objek sebagai respon terhadap suatu event. Activity adalah perilaku yang menentukan urutan langkah-langkah dari proses komputasi yang dilakukan.3) Grouping thingsGrouping things adalah bagian organisasi dari model UML. Grouping things adalah kotak di mana model dapat diuraikan. Contohnya adalah package. 4) Annotational thingsAnnotational things adalah bagian penjelasan dari model UML. Anotational things adalah komentar yang memungkinkan untuk menjelaskan, menerangi, dan member komentar tentang setiap elemen dalam model.

Relationship merupakan bagian dari UML yang berfungsi sebagai penghubung antar-things. Terdapat empat jenis relationship, yaitu : dependency, association, generalization, realization. Jenis-jenis relationship dapat dilihat pada Tabel 2.2.Tabel 2.2. Jenis-jenis RelationshipNo.RelationshipSifatNotasi

1.DependencyHubungan semantik di antara dua model. Perubahan satu elemen akan mengubah elemen lainnya

2. AssociationHubungan struktural di antara class yang mendeskripsikan kumpulan link.

3.Generalizationhubungan di mana unsur khusus (child) dibangun berdasarkan spesifikasi dari elemen umum (parent)

4.RealizationSemantic relationship diantara dua classifier

Diagram merupakan visualisasi grafis yang terdiri atas things dan relationship. Diagram digunakan untuk memproyeksikan suatu sistem yang akan dibangun. Pada UML versi 2 terdapat 13 diagram, beberapa contoh yang nantinya digunakan dalam proses pengembangan sistem adalah sebagai berikut :

1) Use case diagramUse case diagram digunakan untuk menggambarkan interaksi antara pengguna (actor) dengan sistem. Use case diagram terdiri atas notasi untuk use case dan actor. Use case menggambarkan operasi-operasi yang dapat dilakukan oleh sistem sedangkan actor menggambarkan entitas lain (orang, sistem lain, hardware) yang berinteraksi dengan sistem tersebut. Penjelasan komponen dari use case diagram dapat dilihat pada Tabel 2.3. Contoh dari use case diagram dapat dilihat pada Gambar 2.11.

Tabel 2.3. Komponen Use Case DiagramNo.JenisDeskripsiNotasi

1.Aktor Aktor adalah seseorang atau apa saja yang berhubungan langsung dengan sistem yang sedang dibangun.

2.Use CaseUse case adalah bagian tingkat tinggi dari fungsionalitas yang disediakan oleh sistem. Dengan kata lain, use case menggambarkan bagaimana aktor menggunakan sistem.

3.Relasi Asosiasi

Relasi asosiasi adalah relasi antara aktor dengan use case.

4.Relasi ExtendRelasi extend adalah relasi antar use case yang memungkinkan suatu use case secara opsional menggunakan fungsionalitas yang disediakan use case lainnya.

5.Relasi GeneralisasiRelasi generalisasi adalah relasi yang digunakan untuk menunjukkan bahwa beberapa aktor atau use case mempunyai beberapa persamaan.

Gambar 2.11. Contoh Use Case Diagram

Pada contoh terdapat 2 aktor yaitu Customer dan Inventory system dan 3 use case, yaitu Make an Order, payment dan Update Stock serta 3 relasi asosiasi, yaitu customer-make an order, customer-payment dan inventory system-update stock.2) Class diagramClass diagram menggambarkan atribut dan operasi dari sebuah class yang terdapat dalam sebuah sistem. Class diagram juga menggambarkan hubungan antar-class di dalam sistem. Hubungan ini dapat berupa dependency, association, generalization, atau realization. Dalam class diagram dikenal adanya multiplicity yaitu angka yang menunjukan hubungan instansiasi yang mungkin diantara dua buah class. Contoh dari class diagram dapat dilihat pada Gambar 2.12.

Gambar 2.12. Contoh Class DiagramPada contoh terdapat 3 class, yaitu Customer, Order dan Payment serta terdapat 2 hubungan association yang mengandung multiplicity. 3) Sequence diagramSequence diagram digunakan untuk menggambarkan rincian dari sebuah skenario yang terjadi pada masing-masing use case. Melalui sequence diagram juga dapat terlihat urutan-urutan operasi yang terjadi di dalam skenario dan lalu lintas pesan yang terjadi. Sequence diagram menggunakan life line untuk menunjukan waktu hidup dari sebuah objek. Contoh dari sequence diagram dapat dilihat pada Gambar 2.13.

Gambar 2.13. Contoh Sequence Diagram4) Activity diagramActivity diagram menggambarkan berbagai aliran aktivitas yang terjadi di dalam sistem, titik awal dari masing-masing aliran, keputusan yang mungkin terjadi, dan akhir dari aliran aktivitas tersebut. Diagram ini dilengkapi dengan alur percabangan, kondisional, serta sinkronisasi (untuk aktifitas yang dilakukan secara konkuren) untuk menjelaskan aliran aktivitas di dalam sistem. Activity diagram dapat digunakan untuk memodelkan workflow proses bisnis. Untuk membagi aktivitas bisnis ke dalam kelompok-kelompok tertentu sesuai dengan tanggung jawabnya dalam organisasi dapat digunakan notasi swimlane. Swimlane dapat merepresentasikan entitas di dunia nyata seperti unit organisasional dalam sebuah perusahaan. Dalam sebuah activity diagram yang dipartisi ke dalam beberapa swimlane, setiap aktivitas hanya dapat berada pada satu swimlane, tetapi transaksi dapat terjadi antar lane. Penjelasan komponen activity diagram dapat dilihat pada Tabel 2.4, dan contoh activity diagram yang menggunakan swimlane dapat dilihat pada Gambar 2.14.

Gambar 2.14. Contoh Activity Diagram

Tabel 2.4. Komponen Activity DiagramNoJenisDeskripsiNotasi

1ActionMerupakan suatu aksi yang terjadi di dalam sistem

2Initial NodeMerupakan titik awal dari aktivitas sistem

3Final NodeMerupakan titik akhir dari aktifitas sistem

4Flow Final NodeMerupakan node yang mematikan suatu flow. Tidak seperti activity final node yang mematikan semua aktifitas

5DecisionMerupakan node percabangan dari satu flow menjadi beberapa flow dengan kondisi tertentu

6MergeMerupakan node gabungan dari beberapa flow menjadi satu flow

7Fork Merupakan percabangan satu flow menjadi beberapa flow yang berjalan secara konkuren

8JoinMerupakan gabungan dari beberapa flow menjadi satu flow yang berjalan secara konkuren

2.10. Google Maps APIApplication Programming Interface (API) merupakan suatu dokumentasi yang terdiri dari interface, fungsi, kelas, struktur, dan sebagainya untuk membangun sebuah perangkat lunak. Dengan adanya API, maka memudahkan programmer untuk membongkar suatu software untuk kemudian dapat dikembangkan atau diintegrasikan dengan perangkat lunak yang lain.Google Maps API adalah layanan gratis Google yang dapat memberikan fitur Maps pada mobile application atau pun web. Agar google maps dapat muncul di mobile application atau website tertentu, diperlukan adanya API Key. API Key merupakan kode unik yang digenerasikan oleh google untuk mobile application atau website agarserverGoogleMapsdapatmengenali [18].2.11. Object Relational MappingObject Relational Mapping (ORM) adalah suatu metode untuk memetakan object menjadi tabel dalam relational database [1]. Dua konsep dari mapping object ke relational database, yaitu konsep pemetaan dasar dan pemetaan hubungan objek.2.12.1. Konsep Pemetaan DasarAda dua aturan dalam pemetaan dasar yaitu atribut dan class. Pemetaan atribut dilaksanakan dengan memetakan sebuah atribut dalam object menjadi beberapa kolom atau tidak sama sekali. Sedangkan pemetaan class adalah pemetaan setiap class dalam class diagram menjadi sebuah tabel. Contoh dari pemetaan dasar dapat dilihat pada gambar 2.15 [1].

Gambar 2.15. Contoh Pemetaan Dasar [1]

Terlihat pada gambar 2.15 bahwa tidak semua atribut pada class model dipetakan ke dalam physical data model. Karena beberapa atribut tidak perlu dimasukkan ke dalam database. Sebagai contoh pada object tanggal dan object pembelian didapatkan atribut rata-rata yang tidak perlu disimpan kedalam database.2.12.2. Pemetaan Hubungan ObjectAda dua buah kategori hubungan yang harus diperhatikan dalam pemetaan hubungan object, yaitu :1) Kategori multiplicity: kategori berdasarkan multiplicity dari hubungan object. Ada tiga jenis hubungan dalam kategori ini yaitu, one-to-one, one-to-many, dan many-to-many.a) Hubungan one-to-one : hubungan maksimal nilai multiplicity tiap object adalah satu. Pada pemetaan hubungan one-to-one, kunci primer dari salah satu tabel melebur ke tabel yang lain. Peleburan kunci primer tergantung pada arah hubungan antar object atau nilai minimum multiplicity object-nya. Contohnya pada tabel Employee dengan Position yang terlihat pada gambar 2.16 dan hasil mapping-nya pada gambar 2.17.b) Hubungan one-to-many : hubungan maksimal antara dua object dimana object pertama nilai multiplicity tiap object adalah satu, sedangkan object kedua memiliki nilai multiplicity lebih dari satu. Pemetaan pada hubungan ini dilakukan dengan meleburkan kunci primer pada tabel dari object yang memiliki multiplicity satu ke tabel dari object yang memiliki multiplicity lebih dari satu sebagai kunci tamu. Contohnya pada tabel Employee dengan Division yang terlihat pada gambar 2.17.c) Hubungan many-to-many : hubungan maksimal multiplicity tiap object lebih dari satu. Pemetaan pada hubungan ini dilakukan dengan membuat tabel baru dengan field terdiri dari kunci primer dari masing-masing tabel yang terbentuk dari masing-masing object. Contohnya pada tabel Employee dengan Task yang terlihat pada gambar 2.17.2) Kategori directionality : kategori berdasarkan directionality dari hubungan object. Kategori ini memiliki dua jenis hubungan yaitu, hubungan satu arah dan hubungan dua arah.a) Hubungan satu arah, yaitu bila satu object mengacu pada object yang lain. Contohnya pada tabel Employee dengan Position pada gambar 2.16.b) Hubungan dua arah, yaitu bila antar object saling mengacu satu sama lain. Contohnya pada tabel Employee dengan Divition pada gambar 2.16.Contoh hubungan antar objek dapat dilihat pada gambar 2.16, sedangkan contoh hubungan dalam relational database dapat dilihat pada gambar 2.17.

Gambar 2.16. Contoh Hubungan Antar Object [1]

Gambar 2.17. Hubungan dalam Relational Database [1]

2.12. Database Management System MySQLSebuah database management system (DBMS) adalah kumpulan program yang memungkinkan pengguna untuk membuat dan memelihara database [20]. MySQL merupakan salah satu DBMS Sructured Query Language (SQL) bersifat open source paling populer yang dikembangkan, didistribusikan, dan didukung oleh Sun Microsystem [14]. Keandalan MySQL dalam mengolah database ditunjang dengan kecepatannya dalam mengakses perintah query serta banyaknya fitur-fitur yang dimilikinya. Dengan menggunakan konsep client-server, kelebihan dari MySQL adalah cepat, kuat, serta mudah digunakan, sehingga dapat dengan mudah menyimpan, mengubah, dan mengakses data. Segala informasi mengenai MySQL software dapat diakses di MySQL website (http://www.mysql.com/).

ANALISIS DAN PERANCANGAN

Analisis dan perancangan berisi tahap definisi kebutuhan, analisis dan perancangan dalam pengembangan sistem. Ketiganya merupakan core workflow yang terdapat dalam Unified Process.3.1. Definisi KebutuhanDalam subbab ini disajikan definisi kebutuhan perangkat lunak yang meliputi deskripsi umum perangkat lunak, model use case, dan kebutuhan non-functional perangkat lunak. Workflow ini dilakukan pada fase inception hingga awal fase construction.3.1.1. Deskripsi SistemSistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android atau bisa disebut SPANK merupakan sistem yang bertujuan menghasilkan informasi wisata kuliner berdasarkan kriteria dan bobot yang telah dimasukkan oleh pengguna dalam bentuk rangking. SPANK akan memandu dan memberikan informasi seputar lokasi wisata kuliner tujuan. Implementasi pada devices sesungguhnya menggunakan devices Android dengan operating system (OS) Gingerbread dikarenakan Android versi tersebut yang paling banyak dimiliki oleh masyarakat. Gambar 3.1 menunjukkan arsitektur Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android yang dikembangkan.

Gambar 3.1 Arsitektur SPANKPada arsitektur SPANK tersebut digambarkan pengguna yang menggunakan sistem ini melalui device Android. Ketika pengguna mengakses SPANK, sistem tersebut akan mengambil data ke server SPANK. Di dalam server tersebut terdapat file php sebagai web service dan database. Masukan dari pengguna akan dihitung terlebih dahulu oleh web service baru kemudian sistem mengakses database. Administrator terhubung langsung dengan server untuk pengolahan data. Administrator berperan mengelola data melalui halaman admin SPANK menggunakan browser komputer maupun laptop. Pengolahan data tersebut meliputi menambah, mengubah, dan menghapus data. Data yang dikelola administrator berupa data administrator, restoran, dan makanan. Alur proses sistem pendukung keputusan wisata kuliner berbasis GIS pada perangkat android, digambarkan pada activity diagram pada Gambar 3.2.

Gambar 3.2. Activity Diagram SistemTerlihat pada activity diagram tersebut pengguna atau wisatawan dan administrator memiliki aktifitas masing-masing.1) Wisatawan atau pengguna :Pada SPANK untuk pengguna atau wisatawan memiliki 3 aktivitas, yaitu memilih melihat deskripsi SPANK, mencari restoran, dan menghubungi admin.a. Melihat deskripsiSPANK akan menampilkan deskripsi sistem kepada pengguna dalam bentuk text.b. Mencari restoranDalam aktivitas mencari restoran, pengguna memasukkan nama makanan yang akan dicari kemudian SPANK akan melakukan pengecekan apakah makanan tersebut ada dalam database. Setelah makanan ditemukan dalam database, pengguna memasukkan nilai kriteria dan bobot yang diinginkan. Ketika proses itu selesai SPANK akan menampilkan list view restoran berdasarkan hasil perangkingan serta menampilkan lokasi restoran dan lokasi pengguna berdasarkan posisinya (x,y) pada peta.c. Menghubungi adminPengguna dapat menghubungi administrator SPANK dengan mengirim pesan dalam bentuk email.

2) Administrator :Administrator memiliki 2 aktivitas, yaitu mengelola data dan menerima email.a. Mengelola dataSetelah melakukan login, administrator mengolah data berupa data restoran, makanan, serta masing-masing harganya. Pengelolaan yang dilakukan oleh administrator meliputi menambah data, mengubah data, dan menghapus data. Kemudian sistem informasi database SPANK akan memproses pengolahan data yang dilakukan oleh administrator.b. Menerima emailAdministrator menerima email yang ditulis oleh wisatawan atau pengguna.3.1.2. Model Use CaseModel use case terdiri dari definisi actor dan definisi use case yang akan digambarkan ke dalam suatu use case diagram. Use case diagram digunakan untuk menunjukkan hubungan antara actor dan use case.3.1.2.1. Daftar AktorActor yang terlibat dalam pengembangan perangkat lunak ini hanya ada dua yaitu administrator dan pengguna, keterangan dapat dilihat pada Tabel 3.1.Tabel 3.1. Daftar Actor SistemNoActorDeskripsi

1.AdministratorMerupakan pengguna yang diberi otoritas penuh kepada sistem dan dapat menerima email yang dikirimkan oleh pengguna. Administrator berhak mengelola data, meliputi menambah, mengubah, dan menghapus.

2.PenggunaMerupakan semua orang yang menggunakan sistem pendukung keputusan wisata kuliner berbasis GIS pada perangkat android.

3.1.2.2. Daftar Use CaseUse case merupakan deskripsi urutan tindakan yang dilakukan sistem yang berpengaruh kepada actor dari sistem. Terdapat lima use case dalam sistem, yaitu login, kelola data, tentukan preferensi kuliner, hitung nilai masukan dengan metode SAW dan lihat lokasi. Penjelasan masing-masing use case ada pada Tabel 3.2.

Tabel 3.2. Daftar Use Case SistemNoUse CaseDeskripsi

1.LoginAdministrator melakukan login sebelum melakukan pengelolaan data pada halaman admin SPANK.

2.Kelola DataAdministrator mengelola data. Data yang diolah meliputi data administrator, data restoran, dan data makanan. Pengelolaan data yang dapat dilakukan meliputi penambahan, pengubahan dan penghapusan data.

3.Tentukan Preferensi KulinerPengguna memasukkan jenis makanan, nilai kriteria dan bobotnya yang selanjutnya akan dihitung. Kriteria tersebut berupa harga, fasilitas serta jarak.

4.Hitung Nilai Masukan Dengan Metode SAWNilai masukan dari pengguna dihitung oleh sistem dengan menggunakan metode SAW.

5.Lihat Lokasi Pengguna dapat melihat lokasi restoran dari daftar rangking lokasi wisata kuliner hasil perhitungan. Selain itu juga dapat melihat informasi lokasi yang mencakup mengenai nama, alamat, nomor telepon, dan deskripsi restoran.

3.1.2.3. Use Case DiagramUse case diagram disusun berdasarkan daftar actor dan daftar use case dan disusun berdasarkan hubungan keduanya, use case diagram sistem dapat dilihat pada Gambar 3.3.

Gambar 3.3. Use Case Diagram Sistem3.1.2.4. Use Case DetailDetail use case berisi penjelasan dari suatu use case yang meliputi actor yang berinteraksi dengan use case, kondisi awal, kondisi akhir, dan skenario utama yang terjadi pada use case, serta skenario abnormal yang menjelaskan jika terjadi penyimpangan pada skenario utama dari masing-masing use case. Penjelasan detail dari tiap use case adalah sebagai berikut:

1) Use case loginUse case login merupakan use case untuk melakukan login. Detail use case login dapat dilihat pada Tabel 3.3.Tabel 3.3. Detail Use Case LoginNo use case : 1

Nama use case : Use case Login

Aktor : Administrator

Kondisi Awal : Belum mendapat hak akses dan muncul form login

Skenario utama :1. Administrator menuliskan username dan password2. Sistem menyimpan data3. Sistem memproses masukan

Kondisi akhir : Administrator berhasil login dan sistem menampilkan halaman pengelolaan data

Skenario abnormal : Jika username dan password tidak terdapat dalam sistem, maka administrator tidak akan mendapatkan hak aksesnya dan muncul peringatan Login failed, please try again.

2) Use case kelola dataUse case kelola data merupakan use case untuk mengelola data administrator, data restoran, dan data makanan. Detail use case kelola data dapat dilihat pada Tabel 3.4.Tabel 3.4. Detail Use Case Kelola DataNo use case : 2

Nama use case : Use case Kelola Data

Aktor : Administrator

Kondisi Awal : Data administrator, data restoran, dan data makanan belum tersimpan dalam basis data dan tampil halaman list data

Skenario utama :1. Administrator menambah data2. Sistem menyimpan data3. Administrator mengubah data4. Sistem menyimpan perubahan data5. Administrator memilih pilihan hapus untuk data tertentu6. Sistem menghapus data tertentu

Kondisi akhir : Data administrator, data restoran, dan data makanan tersimpan dalam basis data

Skenario abnormal :Jika data yang dimasukkan kosong, maka sistem akan memberikan pesan peringatan.

3) Use case tentukan preferensi kulinerUse case tentukan prefrensi kuliner merupakan use case untuk memberi masukan berupa nama makanan, nilai kriteria serta bobot yang terdiri dari harga, fasilitas serta jarak. Detail use case tentukan preferensi kuliner dapat dilihat pada Tabel 3.5.Tabel 3.5. Detail Use Case Tentukan Preferensi KulinerNo use case : 3

Nama use case : Use case Tentukan Preferensi Kuliner

Aktor : Pengguna

Kondisi Awal : Sistem belum menghitung nilai

Skenario utama :1. Pengguna memasukkan nama makanan yang ingin dicari pada tab explore2. Sistem menampilkan form masukan kriteria dan bobot3. Pengguna memasukkan nilai kriteria dan bobot yang diinginkan4. Sistem menghitung nilai masukan dengan metode SAW

Kondisi akhir : Sistem menampilkan daftar restoran hasil perangkingan

Skenario abnormal : Jika salah satu kriteria belum dimasukan nilainya oleh pengguna, akan muncul alert dialog Nilai belum lengkap, silakan periksa kembali

4) Hitung nilai masukan dengan metode SAWUse case hitung nilai masukan dengan metode SAW merupakan use case untuk menghitung nilai masukan dari pengguna berupa nama makanan serta nilai kriteria dan bobot yang terdiri dari harga, fasilitas serta jarak dengan menggunakan metode SAW. Detail use case hitung nilai masukan dengan metode SAW dapat dilihat pada Tabel 3.6.Tabel 3.6. Detail use case Hitung Nilai Masukan Dengan Metode SAWNo use case : 4

Nama use case : Use case Hitung Nilai Masukan Dengan Metode SAW

Aktor : -

Kondisi Awal : Sistem belum menghitung nilai

Skenario utama :1. Sistem menerima nilai masukan dari pengguna berupa nilai kriteria dan bobot2. Sistem mengoversi nilai masukan dari pengguna3. Sistem melakukan normalisasi terhadap nilai masukan4. Sistem menghitung nilai masukan yang ternormalisasi dengan metode SAW5. Sistem menghasilkan nilai untuk masing-masing alternatif restoran

Kondisi akhir : Sistem menampilkan daftar restoran hasil perangkingan

Skenario abnormal : Jika salah satu kriteria belum dimasukan nilainya oleh pengguna, akan muncul alert dialog Nilai belum lengkap, silakan periksa kembali

5) Lihat lokasiUse case lihat lokasi merupakan use case untuk melihat lokasi restoran dari daftar rangking hasil perhitungan. Selain itu juga dapat melihat informasi lokasi yang mencakup mengenai nama, alamat, nomor telepon, dan deskripsi restoran dari hasil perhitungan yang dilakukan oleh sistem setelah pengguna melakukan perangkingan. Detail use case lihat lokasi dapat dilihat pada Tabel 3.7.Tabel 3.7. Detail Use Case Lihat LokasiNo use case : 5

Nama use case : Lihat Lokasi

Aktor : Pengguna

Kondisi Awal : Sistem belum menampilkan lokasi restoran

Skenario utama :0. Pengguna menentukan nilai0. Sistem akan menampilkan list view wisata kuliner berdasarkan hasil perangkingan.0. Pengguna menekan salah satu list view wisata kuliner untuk melihat detailnya.0. Sistem akan menampilkan informasi wisata kuliner secara lengkap berupa nama, alamat, dan deskripsi restoran.0. Pengguna memilih menu go to map.0. Sistem menampilkan posisi pengguna dan lokasi tujuan serta directions dalam bentuk peta digital

Kondisi akhir : Sistem menampilkan lokasi restoran

Skenario abnormal : Jika GPS belum diaktifkan maka sistem akan menampilkan alert dialog GPS Tidak aktif, Silahkan Hidupkan GPS! berserta button Ok.

3.1.3. Kebutuhan Non-fungsional Perangkat LunakKebutuhan non-fungsional yaitu kebutuhan pembangunan sistem di luar fungsi sistem, meliputi kebutuhan bahasa/lingkungan pemrograman. Kebutuhan non-fungsional sistem pendukung keputusan wisata kuliner berbasis GIS pada perangkat android (SPANK) adalah sebagai berikut :1) Aplikasi dapat diakses dimana dan kapan saja selama terkoneksi dengan internet2) Sistem informasi database SPANK hanya dapat diakses oleh admin3) SPANK dapat digunakan di semua smartphone yang berjalan dengan OS Android 2.3 Gingerbread 4) Menu dan submenu yang ada dapat digunakan dengan jelas. Dengan tampilan yang standar, sehingga memudahkan pengguna yang masih awam terhadap teknologi dapat cepat terbiasa.3.2. AnalisisPada subbab ini dijelaskan mengenai analisis pengembangan sistem. Analisis adalah core workflow yang dominan dilakukan pada fase elaboration. Elaboration adalah fase dari Unified Process yang bertujuan untuk mendefinisikan kebutuhan fungsional dan arsitektur dari sistem. Output dari fase ini meliputi use case realization tahap analisis yang terdiri atas class diagram dan communication diagram. Selain itu fase ini juga akan menghasilkan analysis class.3.2.1. Use Case Realization Tahap AnalisisUse case realization menunjukkan interaksi antara kelas analisis dengan fungsional perangkat lunak. Setiap use case direalisasikan dengan menggunakan communication diagram. Berikut realisasi analisis untuk masing-masing use case:1) LoginRealisasi use case login ditunjukkan dengan class diagram pada Gambar 3.4. Class-class yang terkait pada use case login berdasar pada class diagram tersebut adalah :a) Class boundary: loginb) Class control: Authc) Class entity: administrator, group

Gambar 3.4. Class Diagram Tahap Analisis Login

2) Kelola DataRealisasi use case kelola data ditunjukkan dengan class diagram pada Gambar 3.5. Class-class yang terkait pada use case kelola data berdasar pada class diagram tersebut adalah :a) Class boundary: menuKelolaDatab) Class control: KelolaAdminCtr, KelolaDataCtrc) Class entity: administrator, group, makanan, restoran,sajian

Gambar 3.5. Class Diagram Tahap Analisis Kelola Data3) Tentukan Preferensi KulinerRealisasi use case tentukan preferensi kuliner ditunjukkan dengan class diagram pada Gambar 3.6. Class-class yang terkait pada use case tentukan preferensi kuliner berdasar pada class diagram tersebut adalah :a) Class boundary: ExploreActivityb) Class control: ExploreLokasi, SPK, connectionc) Class entity: restoran, sajian, makanan

Gambar 3.6. Class Diagram Tahap Analisis Tentukan Preferensi Kuliner4) Hitung Nilai Masukan dengan Metode SAWRealisasi use case hitung nilai masukan dengan metode SAW ditunjukan dengan class diagram pada gambar 3.7. Class-class yang ada terletak di sisi server. Class-class yang terkait pada use case hitung nilai masukan dengan metode SAW berdasar pada class diagram tersebut adalah:a) Class boundary: -b) Class control: SPK, connectionc) Class entity: restoran, sajian, makanan

Gambar 3.7. Class Diagram Hitung Nilai Masukan dengan Metode SAW5) Lihat lokasiRealisasi use case lihat lokasi ditunjukkan dengan class diagram pada Gambar 3.8. Class-class yang terkait pada use case lihat lokasi berdasar pada class diagram tersebut adalah :a) Class boundary: HasilActivityb) Class control: ListViewLokasi, PetaLokasi, getLokasi, connectionc) Class entity: restoran, sajian, makanan

Gambar 3.8. Class Diagram Tahap Analisis Lihat Lokasi3.2.2. Analysis ClassAnalysis class pada pengembangan sistem pendukung keputusan wisata kuliner berbasis GIS pada perangkat android diperoleh hasil identifikasi kelas pada workflow analisis. Kelas-kelas yang diidentifikasi ditunjukkan pada Tabel 3.8.Tabel 3.8. Hasil Identifikasi Analysis ClassNoNama Analysis ClassJenis Kelas

1.LoginBoundary

2.menuKelolaDataBoundary

3.ExploreActivityBoundary

4.HasilActivityBoundary

5.AuthControl

6.KelolaAdminCtrControl

7.KelolaDataCtrControl

8.ExploreLokasiControl

9.SPKControl

10.ListViewLokasiControl

11.PetaLokasiControl

12.GetlokasiControl

13.connectionControl

14.administratorEntity

15.GroupEntity

16.RestoranEntity

17.SajianEntity

18.makananEntity

Setiap kelas memiliki tanggung jawab, yaitu hal yang harus dilakukan setiap kelas dan memiliki atribut atau properti. Tanggung jawab dan atribut analysis class yang teridentifikasi ditunjukkan pada Tabel 3.9.

Tabel 3.9. Daftar Tanggung Jawab dan Atribut Analysis ClassNoNama Analysis ClassTanggung JawabAtribut

1.LoginMenampilkan halaman login-

2.menuKelolaDataMenampilkan halaman kelola data administrator, kelola restoran dan kelola makanan-

3.ExploreActivityMenampilkan form input kepada user untuk memasukkan nilai.-

4.HasilActivityMenampilkan hasil perhitungan dalam bentuk list view-

5.AuthMengontrol authentication login-

6.KelolaAdminCtrMengontrol data administrator-

7.KelolaDataCtrMengontrol data restoran, makanan, dan sajian-

8.ExploreLokasiMengontrol nilai yang di-input-kan oleh user-

9.SPKSebagai web service untuk mengontrol perhitungan nilai input-an menggunakan metode SAW-

10.ListViewLokasiMengontrol list view lokasi yang akan ditampilkan-

11.PetaLokasiMengontrol lokasi pengguna dengan lokasi restoran tujuan dalam bentuk peta digital-

12.GetlokasiSebagai web service, untuk mengontrol peta lokasi dalam menampilkan posisi restoran pada peta digital sesuai dengan hasil perangkingan-

13.ConnectionMengontrol koneksi ke database.-

14.AdministratorMenyimpan data administrator1) admin_id2) username3) password4) group_id5) date_reg6) last_login

15.GroupMenyimpan data group1) group_id2) group_name

16.RestoranMenyimpan informasi restoran1) id_resto2) nm_resto3) alamat4) tlp5) latitude6) longitude7) keterangan8) image9) parkir10) ac11) wifi12) meetr13) toilet14) mushola15) music

17.SajianMenyimpan data harga makanan yang disajikan oleh tiap restoran1) id_resto2) id_makanan3) harga

18.MakananMenyimpan data makanan1) id_makanan2) nm_makanan

3.3. PerancanganSubbab ini menjelaskan mengenai tahap perancangan, yaitu core workflow dominan pada fase elaboration dan construction. Output dari workflow ini berupa use case reaslization tahap perancangan yang terdiri dari class diagram. Fase ini juga menghasilkan design class.

3.3.1. Use Case Realization Tahap PerancanganUse case realization tahap perancangan merupakan kolaborasi design class dan objek-objek yang merealisasikan use case. Setiap use case pada tahap ini direalisasikan dalam class diagram dan sequence diagram. Berikut dijabarkan realisasi masing-masing use case tahap perancangan :1) LoginRealisasi use case login administrator ditunjukkan pada class diagram Gambar 3.9 dan sequence diagram pada Gambar 3.10. Class-class yang terkait dengan use case login pada tahap perancangan adalah :a) Class boundary: loginb) Class control: Authc) Class entity: administrator, group

Gambar 3.9. Class Diagram Tahap Perancangan Login

Gambar 3.10. Sequence Diagram Login2) Kelola DataRealisasi use case kelola data ditunjukkan pada class diagram Gambar 3.11 dan sequence diagram pada Lampiran A.1. Class-class yang terkait dengan use case kelola data pada tahap perancangan adalah :a) Class boundary: menuKelolaDatab) Class control: KelolaAdminCtr, KelolaDataCtrc) Class entity: administrator, group, restoran, sajian,makanan

Gambar 3.11. Class Diagram Tahap Perancangan Kelola Data3) Tentukan Preferensi KulinerRealisasi use case tentukan preferensi kuliner ditunjukkan pada class diagram Gambar 3.12 dan sequence diagram pada Lampiran A.2. Class-class yang terkait dengan use case tentukan preferensi kuliner pada tahap perancangan adalah :a) Class boundary: ExploreActivityb) Class control: ExploreLokasi, SPK, connectionc) Class entity: restoran, sajian, makanan

Gambar 3.12. Class Diagram Tahap Perancangan Tentukan Preferensi Kuliner4) Hitung Nilai Masukan dengan Metode SAWRealisasi use case hitung nilai masukan dengan metode SAW ditunjukkan pada class diagram Gambar 3.13. Class-class yang terkait dengan use case hitung nilai masukan dengan metode pada tahap perancangan adalah :a) Class boundary: -b) Class control: SPK, connectionc) Class entity: restoran, sajian, makanan

Gambar 3.13. Class Diagram Tahap Perancangan Hitung Nilai Masukan dengan Metode SAW5) Lihat LokasiRealisasi use case lihat lokasi ditunjukkan pada class diagram Gambar 3.14 dan sequence diagram pada Lampiran A.3. Class-class yang terkait dengan use case lihat lokasi pada tahap perancangan adalah :a) Class boundary: HasilActivityb) Class control: ListViewLokasi, PetaLokasi, getLokasi, connectionc) Class entity: restoran, sajian, makanan

Gambar 3.14. Class Diagram Tahap Perancangan Lihat Lokasi3.3.2. Design ClassDesign class pada pengembangan sistem pendukung keputusan wisata kuliner berbasis GIS pada perangkat android diperoleh dari identifikasi class-class realisasi use case pada tahap analis. Hasil identifikasi design class ditunjukkan pada Tabel 3.10 yang berisi nama kelas dan kelas acuan dari analysis class.

Tabel 3.10. Hasil Identifikasi Design ClassNoNama Design ClassNama Analysis Class

1.LoginLogin

2.menuKelolaDatamenuKelolaData

3.ExploreActivityExloreActivity

4.HasilActivityHasilActivity

5.AuthAuth

6.KelolaAdminCtrKelolaAdminCtr

7.KelolaDataCtrKelolaDataCtr

8.ExploreLokasiExploreLokasi

9.SPKSPK

10.ListViewLokasiListViewLokasi

11.PetaLokasiPetaLokasi

12.getlokasiGetlokasi

13.connectionConnection

14.administratorAdministrator

15.GroupGroup

16.restoranRestoran

17.SajianSajian

18.makananMakanan

3.3.3. Perancangan Basis DataSistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android ini menggunakan basis data relasional. Oleh karena itu, perlu dilakukan mapping dari class diagram entity ke skema basis data relasional. Hasil mapping tersebut dapat dilihat pada Tabel 3.11. Terdapat 4 tabel yang dibuat pada basis data pengembangan Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android (SPANK). Hasil perancangan dapat dilihat pada Gambar 3.13.

Tabel 3.11. Hasil identifikasi tabelNo.Nama Entity ClassNama Tabel

1.AdministratorAdministrator

2.GroupGroup

3.RestoranRestoran

4.SajianSajian

5.MakananMakanan

Gambar 3.15. ORM Diagram SPANK3.3.4. Perancangan AntarmukaPerancangan antarmuka digunakan untuk merepresentasikan bentuk Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android. Halaman pertama dari perancangan antarmuka SPANK adalah tab home, yang ditunjukan pada Gambar 3.16.

Gambar 3.16. Rancangan Antarmuka Tab Home SPANKBerikut ini adalah perancangan antarmuka untuk use case Login, Kelola Data, Tentukan Preferensi Kuliner, dan Lihat Lokasi.1. LoginDesain antarmuka login digambarkan pada Gambar 3.17, merupakan desain antarmuka yang termasuk dalam use case login. Pada form ini terdapat 2 label, 2 text box, dan 1 button.

Gambar 3.17. Desain Antarmuka Login2. Kelola DataDesain antarmuka tambah data administrator digambarkan pada Gambar 3.18, merupakan desain antarmuka yang termasuk dalam use case kelola data. Pada form terdapat 3 label, 2 text box, 1 non aktif text box, dan 1 button.

Gambar 3.18. Desain Antarmuka Tambah Data AdministratorDesain antarmuka tambah data makanan digambarkan pada Gambar 3.19 merupakan desain antarmuka yang termasuk dalam use case kelola data. Pada form terdapat 1 label, 1 text box, serta 1 button.

Gambar 3.19. Desain Antarmuka Tambah Data MakananSedangkan desain antarmuka tambah data restoran digambarkan pada Gambar 3.20 merupakan desain antarmuka yang termasuk dalam use case kelola data. Pada form terdapat 8 label, 6 text box, 8 combo box, dan 2 button.

Gambar 3.20. Desain Antarmuka Tambah Data Restoran3. Tentukan Preferensi KulinerDesain antarmuka tentukan preferensi kuliner terbagi menjadi beberapa alur atau tahap. Desain antarmuka tentukan preferensi kuliner digambarkan pada Gambar 3.21. Pada gambar 3.21 menampilkan sebuah alur gambar dari desain antarmuka menentukan preferensi kuliner. Berikut desain antarmuka menentukan preferensi kuliner dari use case tentukan preferensi kuliner:1) Gambar 3.21 nomor 1 yaitu tab Explore menampilkan petunjuk untuk melakukan perangkingan menggunakan SPANK serta tombol start explore. Jika tombol tersebut diklik akan terlihat pada gambar 3.19 nomor 2.2) Gambar 3.21 nomor 2 menampilkan text box. Text box ini digunakan oleh pengguna untuk memasukkan nama makanan yang ingin dicari atau dilakukan perangkingan. Setelah pengguna memasukkan nama makanan yang akan dicari dan menekan tombol next, akan muncul pesan apakah makanan tersebut ada di database SPANK atau tidak. Jika tidak, pengguna diminta untuk memasukkan nama makanan lainnya. Jika ada maka akan terlihat pada gambar 3.21 nomor 3.3) Gambar 3.21 nomor 3 menampilkan form input untuk diisi nilai kriteria dan bobot sesuai keinginan pengguna yang nantinya akan dihitung.

Gambar 3.21. Desain antarmuka Tentukan Preferensi Kuliner

4. Lihat LokasiDesain antarmuka lihat lokasi digambarkan pada Gambar 3.22, merupakan desain antarmuka yang termasuk dalam use case lihat lokasi. Berikut desain antarmuka lihat lokasi dari use case lihat lokasi :1) Pada Gambar 3.22 nomor 1 menampilkan list view hasil perangkingan pengguna yang didapat dari perhitungan sebelumnya. Untuk setiap list memiliki item image view dan text view untuk nama restoran. Jika salah satu list diklik akan terlihat pada gambar 3.22 nomor 2.2) Gambar 3.22 nomor 2 menampilkan detail restoran mulai dari gambar, nama restoran, alamat restoran, nomer telepon restoran serta deskripsi restoran. Jika tombol go to maps diklik akan terlihat pada gambar 3.22 nomor 3.3) Gambar 3.22 nomor 3 menampilkan posisi pengguna dan posisi restoran pada peta serta direction menuju lokasi restoran.

Gambar 3.22. Desain Antarmuka Lihat Lokasi

IMPLEMENTASI DAN PENGUJIAN

Bab ini berisi implementasi dan juga pengujian dari Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android.4.1. ImplementasiImplementasi dilakukan menggunakan perangkat komputer dan juga gadget dengan OS Android. Perangkat keras yang digunakan untuk pengembangan adalah sebagai berikut :1) PC Intel(R) Core(TM) i5 CPU M 460 @ 2.53 GHz2) RAM 2 GB3) Resolusi monitor 1280x8004) Audio Adapter : Intel 82801HB ICH8 - High Definition Audio [B1]5) Network Card : Intel PRO/Wireless 3945ABG Network Connection (HP - MOW1)6) Harddisk 195 Gb7) Optical mouse standar8) Android Device OS Ver.2.3.6 GingerbreadSedangkan perangkat lunak yang digunakan untuk pengembangan adalah sebagai berikut:1) Sistem Operasi Windows 7 Ultimate2) Eclipse Juno 3) Android Development Tools (ADT) plugin4) Android Software Development Kit (SDK)5) Xampp 1.7.44.1.1. Implementasi Basis DataImplementasi basis data merupakan transformasi rancangan data yang dihasilkan dari proses perancangan basis data menjadi suatu basis data untuk Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android (SPANK). Berikut adalah implementasi basis data untuk SPANK:

1) AdministratorImplementasi basis data dari tabel administrator ditunjukan pada kode 4.1.Kode 4.1. Implementasi tabel administratorCREATETABLE`adminspk`.`administrator`(`admin_id`INT(11)NOTNULLAUTO_INCREMENT,`username`VARCHAR(255)NOTNULL,`password`VARCHAR(255)NOTNULL,`group_id`INT(11)NOTNULL,`date_reg`DATETIMENOTNULL,`login_last`DATETIMENOTNULL,PRIMARYKEY(`admin_id`));

2) GroupImplementasi basis data dari tabel group ditunjukan pada kode 4.2.Kode 4.2. Implementasi tabel groupCREATETABLE`adminspk`.`group`(`group_id`INT(11)NOTNULLAUTO_INCREMENT,`group_name`VARCHAR(50)NOTNULL,PRIMARYKEY(`group_id`));

3) MakananImplementasi basis data dari tabel makanan ditunjukan pada kode 4.3.Kode 4.3. Implementasi tabel makananCREATETABLE`adminspk`.`makanan`(`id_makanan`INT(11)NOTNULLAUTO_INCREMENT,`nm_makanan`VARCHAR(30)NOTNULL,PRIMARYKEY(`id`));

4) RestoranImplementasi basis data dari tabel restoran ditunjukan pada kode 4.4.Kode 4.4. Implementasi tabel restoranCREATETABLE`adminspk`.`restoran`(`id_resto`INT(11)NOTNULLAUTO_INCREMENT,`nm_resto`VARCHAR(100)NOTNULL,`alamat`TEXTNOTNULL,`tlp`VARCHAR(15)NOTNULL,`latitude`DOUBLENOTNULL,`longitude`DOUBLE NOTNULL,`keterangan`TEXTNOTNULL,`image`VARCHAR(100)NOTNULL,`parkir`ENUM(tidak,ada)NOTNULL,`ac`ENUM(tidak,ada)NOTNULL,`wifi`ENUM(tidak,ada)NOTNULL,`meetr`ENUM(tidak,ada)NOTNULL,`toilet`ENUM(tidak,ada)NOTNULL,`mushola`ENUM(tidak,ada)NOTNULL,`musik`ENUM(tidak,ada)NOTNULL,PRIMARYKEY(`id`));

5) SajianImplementasi basis data dari tabel sajian ditunjukan pada kode 4.5.Kode 4.5. Implementasi tabel sajianCREATETABLE`adminspk`.`sajian`(`id_resto`INT(11)NOTNULLAUTO_INCREMENT,`id_makanan`INT(11)NOTNULL,`harga`INT(11)NOTNULL,KEY `id_resto` (`id_resto`),KEY `id_makanan` (`id_makanan`));

ALTER TABLE sajian ADD CONSTRAINT `id_resto` FOREIGN KEY (`id_resto`) REFERENCES`restoran` (`id_resto`) ON DELETE CASCADE ON UPDATE CASCADE;ALTER TABLE `sajian` ADD CONSTRAINT `id_makanan` FOREIGN KEY (`id_makanan`) REFERENCES`makanan` (`id_makanan`) ON DELETE CASCADE ON UPDATE CASCADE;

4.1.2. Implementasi ClassImplementasi class pada pengembangan Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android (SPANK) dapat dilihat pada Tabel 4.1. Implementasi dari class SPK dapat dilihat pada Lampiran B. Implementasi Class.

Tabel 4.1. Implementasi ClassNoClass PerancanganClass ImplementasiNama File

1.LoginLogin.../view/login.php

2.menuKelolaDatamenuKelolaData.../view/menuKelolaData.php

3.ExploreActivityExploreActivity.com.ta.okky.spank.ExploreActivity.java

4.HasilActivityHasilActivity.com.ta.okky.spank.HasilActivity.java

5.AuthAuth.../libraries/Auth.php

6.KelolaAdminCtrKelolaAdminCtr.../control/kelolaAdminCtr.php

7.KelolaDataCtrKelolaDataCtr.../control/kelolaDataCtr.php

8.ExploreLokasiExploreLokasi.com.ta.okky.spank.ExploreLokasi.java

9.ListViewLokasiListViewLokasi.com.ta.okky.spank. HasilActivity.java

10.PetaLokasiPetaLokasi.com.ta.okky.spank.PetaLokasi.java

11GetLokasiGetLokasi../service/client/spank/GetLokasi.php

12.SPKSPK../service/client/spank/SPK.php

13.ConnectionConnection../service/client/spank/connection.php

14.AdministratorAdministrator-

15.GroupGroup-

16.RestoranRestoran-

17.SajianSajian-

18.MakananMakanan-

4.1.3. Implementasi AntarmukaPada sub bab ini disajikan implementasi antarmuka dari use case yang telah diidentifikasi pada workflow sebelumnya. Halaman pertama dari implementasi antarmuka SPANK adalah tab home, yang ditunjukan pada gambar 4.1.

Gambar 4.1. Tampilan tab Home SPANKBerikut ini adalah implementasi antarmuka untuk use case Login, Kelola Data, Tentukan Preferensi Kuliner, dan Lihat Lokasi. 1. LoginImplementasi antarmuka use case login dapat dilihat pada Gambar 4.2.

Gambar 4.2. Tampilan Halaman LoginPada Gambar 4.2 menunjukkan implementasi halaman login pada Sistem Informasi Database SPANK yang termasuk dalam use case lakukan login. Implementasi antarmuka halaman ini terdiri atas form untuk login. Field yang harus diisi yaitu username dan password serta terdapat 1 tombol yaitu tombol log in.

2. Kelola DataImplementasi antarmuka use case kelola data terbagi menjadi beberapa tampilan meliputi kelola data administrator, kelola data makanan, dan kelola data restoran. a. Mengelola data administratorImplementasi antarmuka use case kelola data administrator dapat dilihat pada Gambar 4.3.

Gambar 4.3. Tampilan Halaman Tambah Data Administrator

Pada Gambar 4.3 menunjukkan implementasi halaman tambah data administrator SPANK yang termasuk dalam use case kelola data. Implementasi antarmuka halaman ini terdiri atas form yang dapat digunakan untuk menambah data administrator. Field yang harus diisi yaitu username, dan password serta terdapat 1 tombol simpan. Sedangkan untuk field group tidak perlu diisi karena sudah otomatis tersimpan dengan value administrator.

b. Kelola data makananImplementasi antarmuka kelola data makanan dapat dilihat pada Gambar 4.4.

Gambar 4.4. Tampilan Halaman Tambah Data MakananPada Gambar 4.4 menunjukkan implementasi halaman tambah data makanan yang termasuk dalam use case kelola data. Implementasi antarmuka halaman ini terdiri atas form yang dapat digunakan untuk menambah data makanan. Field yang harus diisi yaitu nama makanan serta terdapat 1 tombol simpan.

c. kelola data restoranImplementasi antarmuka use case kelola data restoran dapat dilihat pada Gambar 4.5. Pada Gambar 4.5 menunjukkan implementasi halaman tambah data restoran SPANK yang termasuk dalam use case kelola data. Implementasi antarmuka halaman ini terdiri atas form yang dapat digunakan untuk menambah data restoran. Field-field yang harus diisi yaitu nama, alamat, no.telepon, deskripsi, fasilitas, latitude, dan longitude, serta terdapat 1 tombol yaitu tombol simpan. Field foto / gambar adalah field optional, jika tidak memiliki foto atau gambar restoran yang bersangkutan tidak perlu mengisinya.

Gambar 4.5. Tampilan Halaman Tambah Data Restoran3. Tentukan Preferensi KulinerImplementasi antarmuka tentukan preferensi kuliner terbagi menjadi beberapa bagian atau tahap. Implementasi antarmuka tentukan preferensi kuliner dapat dilihat pada Gambar 4.6. Pada gambar 4.6 menampilkan sebuah alur gambar dari implementasi antarmuka tentukan preferensi kuliner. Berikut penjelasan dari gambar 4.6 :1) Gambar 4.6 nomor 1 menampilkan petunjuk untuk melakukan perangkingan menggunakan SPANK pada tab menu explore. Pada tab menu explore juga terdapat tombol start explore. Ketika tombol tersebut diklik maka akan menuju halaman selanjutnya berupa form input nama makanan pada gambar 4.6 nomor 2. 2) Gambar 4.6 nomor 2 menampilkan form input berupa text box. Text box ini digunakan oleh pengguna untuk memasukkan nama makanan yang ingin dicari atau dilakukan perangkingan. Setelah pengguna memasukkan nama makanan yang akan dicari dan menekan tombol next, akan muncul pesan apakah makanan tersebut ada di database SPANK atau tidak. Jika tidak, pengguna diminta untuk memasukkan nama makanan lainnya. Jika makanan yang dimasukkan ada di database maka akan dilanjutkan ke form input untuk nilai kriteria dan bobot seperti yang terlihat pada Gambar 4.6 nomor 3. 3) Gambar 4.6 nomor 3 menampilkan form input untuk nilai kriteria dan bobot yang dapat diisi sesuai keinginan pengguna yang nantinya nilai tersebut akan dihitung.

Gambar 4.6. Tampilan Antarmuka Tentukan Preferensi Kuliner4. Lihat LokasiImplementasi antarmuka use case lihat lokasi dapat dilihat pada Gambar 4.7. Pada Gambar 4.7 menampilkan sebuah alur gambar dari implementasi antarmuka lihat lokasi. Berikut penjelasan dari Gambar 4.7.1) Pada Gambar 4.7 nomor 1 menampilkan list view hasil perangkingan pengguna yang didapat dari perhitungan sebelumnya. Untuk setiap list memiliki item image view dan text view untuk nama restoran. Jika salah satu list diklik akan terlihat pada gambar 4.7 nomor 2.2) Gambar 4.7 nomor 2 menampilkan detail restoran mulai dari gambar, nama restoran, alamat restoran, nomer telepon restoran serta deskripsi restoran. Jika tombol go to maps diklik akan terlihat pada gambar 4.7 nomor 3.3) Gambar 4.7 nomor 3 menampilkan posisi restoran pada peta Google Maps.

Gambar 4.7. Tampilan Antarmuka Lihat Lokasi4.2. PengujianPengujian perangkat lunak Sistem Pendukung Keputusan Wisata Kuliner Berbasis GIS pada Perangkat Android (SPANK) dilakukan dengan metode black box, yaitu menguji fungsionalitas dari perangkat lunak, tanpa harus mengetahui struktur internal program. Sebuah perangkat lunak yang diuji menggunakan metode black-box dikatakan berhasil jika fitur-fitur yang ada telah memenuhi spesifikasi requirements (use case) yang telah dibuat sebelumnya.Selain itu class SPK juga akan diuji struktur logika programnya dengan metode white box. Pengujian ini dilakukan untuk meyakinkan bahwa semua operasi internal bekerja sesuai dengan spesifikasi yang ditentukan.4.2.1. Lingkungan PengujianLingkungan pengujian meliputi perangkat keras dan perangkat lunak yang digunakan dalam proses pengujian. Perangkat keras yang digunakan dalam pengujian SPANK ini adalah :1) PC Intel(R) Core(TM) i5 CPU M 460 @ 2.53 GHz2) RAM 2 GB3) Resolusi monitor 1280x8004) Network Card : Intel PRO/Wireless 3945ABG Network Connection (HP - MOW1)5) Harddisk 195 Gb6) Android Device OS Ver.2.3.6 GingerbreadSedangkan perangkat lunak yang digunakan untuk pengembangan adalah sebagai berikut:1) Sistem Operasi Windows 7 Ultimate2) Eclipse Juno3) Android Development Tools (ADT)4) Android Software Development Kit (SDK)5) Xampp 1.7.44.2.2. Rencana PengujianRencana pengujian SPANK dapat dilihat pada Tabel 4.2. Terdapat 4 use case yang akan diuji yaitu use case melakukan otentikasi administrator, mengelola data, menentu