BAB II LANDASAN TEORI

BAB II LANDASAN TEORI

2.1

Pencarian Rute Lari

2.1.1 Algoritma Haversine Formula Algoritma Haversine Formula adalah persamaan penting dalam dalam navigasi, memberikan besar-lingkaran jarak antara dua titik pada lingkup dari bujur dan lintang. Ini merupakan kasus khusus dari formula yang lebih umum pada trigonometri bola. Algoritma ini nantinya akan digunakan untuk menghitung jarak antara dua titik GPS. Dalam hal ini adalah titik GPS teknisi dan titik GPS unit, sehingga algoritma ini menjadi kunci utama untuk menentukan pemilihan tugas yang akan diberikan pada teknisi. Berikut salah satu rumus haversine untuk setiap 2 titik pada bola

Dimana: Haversine (θ) = sin2 (θ/2) = (1-cos θ))/2 Φ1 = garis lintang (latitude) dari titik 1 d = jarak dua titik (antara unit dan teknisi) Φ2 = garis lintang (latitude) dari titik 2 R = jari-jari bola (radius bumi) Δλ = pemisah bujur (longitude) Perlu

diketahui

bahwa

argumen

untuk

fungsi

haversine

diasumsikan disini untuk diberikan dalam radian. Dalam derajat, haversine (d /

) dalam rumus akan menjadi haversine (1 0 d / Π ). Mengingat

lingkup pada haversine merupakan segitiga pada permukaan bola yang didefinisikan oleh lingkaran-lingkaran besar yang menghubungkan tiga titik u, v, dan w pada bola.

6 http://digilib.mercubuana.ac.id/

Gambar 2.1 Segitiga Bola Haversine Jika panjang dari ketiga sisi adalah A (u ke v), b (dari u untuk w), dan c (dari v ke w), dan sudut sudut c sebaliknya adalah C, maka hukum haversine sebagai berikut: Haversine (c) = haversine (a-b) + sin (b) haversin (c) Karena ini adalah lingkup unit, panjang a, b, dan c hanya sama dengan sudut (dalam radian) dengan sisi dari pusat bola sedangkan untuk lingkup non-unit, masing-masing sama panjang busut untuk sudut pusat yang dikalikan dengan jari-jari bola. Jika dalam satu kasus khusus dimana U adalah kutub utara, sementara v dan w adalah dua poin pemisah yang akan ditentukan dalam hal ini, a dan b adalah Π/2 - Φ1, 2 (yaitu 0 - lintang), C adalah longitude Δλ pemisahan, dan c adalah dikehendaki d / . Memperhatikan bahwa haversine (Π/2 – Φ) = cos (Φ), maka haversin-nya akan menjadi sebagai berikut: Cos (c) = cos (a) cos (b) + sin (a) sin (b) cos (c) R <-6371 α <-sin((Φ1- Φ2/2)2+cos(Φ1)*cos(Φ1)*sin(Δγ/2)2 β <-2*atan2(√(α), √(1-α)) d <-R* β Gambar 2.2 Pseudocode Haversine Formula


2.2

Rekayasa Perangkat Lunak Rekayasa perangkat lunak adalah suatu disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal yaitu analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna, disain, pengkodean, pengujian sampai pemeliharaan sistem setelah digunakan (Yasin, 2012) . Dari pengertian tersebut jelaslah bahwa Rekayasa Perangkat lunak tidak hanya berhubungan dengan cara pembuatan program komputer. Pernyataan “semua aspek produksi” pada pengertian diatas, mempunyai arti semua hal yang berhubungan dengan proses produksi seperti manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas sampai dengan pelatihan pengguna merupakan bagian dari RPL. Rekayasa perangkat lunak lebih fokus pada praktik pengembangan perangkat lunak dan mengirimkan perangkat lunak yang bermanfaat kepada pelanggan. Adapun ilmu komputer lebih fokus pada teori dan konsep dasar perangkat komputer, rekayasa perangkat lunak lebih fokus pada bagaimana membuat perangkat lunak yang memenuhi kriteria berikut: 

Dapat terus dipelihara setelah perangkat lunak selesai dibuat seiring

berkembangnya

tekonologi

dan

lingkungan

(maintainability). 

Dapat diandalkan dengan proses bisnis yang dijalakan dan perbuhan yang terjadi (dependentbility dan robust).



Efisien dari segi sumber daya dan penggunaan.



Kemampuan untuk dipakai sesuai dengan kebutuhan (usability). Dari kriteria diatas maka perangkat lunak yang baik adalah

perangkat lunak yang dapat memenuhi kebutuh pelanggan (customer) atau pengguna (user) atau berorientasi pada pelanggan atau pemakai perangkat lunak, bukan berorientasi pada pembuat atau pengembang perangkat lunak.


2.2.1

Ruang Lingkup Rekayasa Perangkat Lunak Ruang lingkup Rekayasa perangkat lunak dapat digambarkan sebagai berikut :

Gambar 2.3 Ruang Lingkup Rekayasa Perangkat Lunak (Verdi, 2012:4)

2.2.2

Software Development Life Cycle Pada awal pengembangan perangkat lunak, para pembuat program (programmer) langsung melakukan pengodean perangkat lunak tanpa menggunakan prosedur atau tahapan pengembangan perangkat lunak. Dan ditemuilah kendala-kendala seiring dengan perkembangan skala sistemsistem perangkat yang semakin besar. SDLC atau Software Development Life Cycle adalah proses mengembangkan atau mengubah suatu sistem perangkat lunak dengan menggunakan model-model dan metodologi yang digunakan orang untuk mengembangkan sistem-sistem perangkat lunak sebelumnya (berdasarkan best practice atau cara-cara yang sudah teruji baik). Seperti halnya proses metamorfosis pada kupu-kupu, untuk menjadi kupu-kupu yang indah maka

dibutuhkan beberapa tahap untuk dilalui, sama halnya dengan

membuat perangkat lunak, memiliki daur tahapan yang dilalui agar menghasilkan perangkat lunak yang berkualitas (S & Shalahuddin, 2013).


Tahapan-tahapan yang ada pada SDLC secara global adalah sebagi berikut: 

Inisiasi (initiation) Tahapan ini biasasnya ditandai dengan pembuatan proposal proyek perangkat lunak.



Pengembangan konsep sistem (system concept development) Mendefinisikan lingkup konsep termasuk dokumen lingkup sistem, analisis manfaat biaya, manajemen rencana, dan pembelajaran kemudahan sistem.



Perencanaan (planning) Mengembangkan rencana manajemen proyek dan dokumen perencanaan lainnya. Menyediakan dasar untuk mendapatkan sumber daya (resources) yang dibutuhkan untuk memperoleh solusi.



Analisis kebutuhan (requirement analysis) Menganalisis kebutuhan pemakai sistem perangkat lunak (user) dan mengembangkan kebutuhan user. Membuat dokumen kebutuhan fungsional.



Desain (design) Mentransformasikan kebutuhan detail menjadi kebutuhan yang sudah lengkap, dokumen desain sistem fokus pada bagaimana dapat memenuhi fungsi-fungsi yang dibutuhkan.



Pengembangan (development) Mengkonversi desain ke sistem informasi yang lengkap termasuk bagaimana memperoleh dan melakukan instalasi lingkungan sistem yang dibutuhkan; membuat basis data dan mempersiapkan prosedur kasus pengujian; mempersiapkan berkas atau file pengujian, pengkodean, pengompilasian, memperbaiki dan membersihkan program; peninjauan pengujian.

 Integrasi dan pengujian (integration dan test) Mendemonstrasikan sistem perangkat lunak bahwa telah memenuhi kebutuhan

yang

dispesifikasikan


pada

dokumen

kebutuhan

fungsional. Dengan diarahkan oleh staf penjamin kualitas (quality assurance) dan user. Menghasilkan laporan analisis pengujian. 

Implementasi (implementation) Termasuk pada persiapan implementasi, implementasi perangkat lunak pada lingkungan produksi (lingkungan pada user) dan menjalankan resolusi dari permasalahan yang teridentifikasi dari fase integrasi dan pengujian.



Operasi dan pemeliharaan (operations and maintenance) Mendeskripsikan pekerjaan untuk mengoperasikan dan memlihara sistem informasi pada lingkungan produksi (lingkungan pada user), termasuk implementasi akhir dan masuk pada proses peninjauan.



Disposisi (disposition) Mendeskripsikan aktifikas akhir dari pengembangan sistem dan membangun data yang sebenarnya sesuai dengan aktivitas user.

2.2.3

Model Waterfall Model SDLC air terjun (waterfall) sering juga disebut sebagai model sekuensial linier (sequential linear) atau alur hidup klasik (classic life cycle). Model air terjun menyediakan pendekatan alur hidup perangkat lunak secara sekuensial atau terurut dimulai dari analisis, desain, pengodean, pengujian, dan tahap pendukung (support). Berikut adalah gambar dari model air terjun:


Analisis

Desain

Pengodean

Pengujian

Pemeliharaan

Gambar 2.4 Ilustrasi Model Waterfall 

Analisa kebutuhan perangkat lunak Proses pengumpulan kebutuhan dilakukan scara intensif untuk menspesifikasikan kebutuhan perangkat lunak agar dapat dipahami perangkat lunak seperti apa yang dibutuhkan oleh user. Spesifikasi kebutuhan

perangkat

lunak

pada

tahap

ini

perlu

untuk

didokumentasikan. 

Desain Desain perangkat lunak adalah proses multi langkah yang fokus pada desain pembuatan program perangkat lunak termasuk struktur data, arsitektur perangkat lunak, representasi antarmuka, dan prosedur pengodean. Tahap ini mentranslasikan kebutuhan perangkat lunak dari tahap analisis menjadi representasi desain agar dapat diimplementasikan mejadi program pada tahap selanjutnya. Desain perangkat lunak yang dihasilkan pada tahap ini juga perlu untuk didokumentasikan.



Pembuatan kode program


Desain harus ditranslasikan ke dalam program perangkat lunak. Hasil dari tahap ini adalah program komputer sesuai dengan desain yang telah dibuat pada tahap desain. 

Pengujian Pengujian fokus pada perangkat lunak secara logika dan fungsional dan memastika bahwa semua bagia sudah diuji. Hal ini dilakukan untuk meminimalisir kesalahan (error) dan memsatikan keluaran yang dihasilkan sesuai dengan yang diinginkan.



Pendukung atau Pemeliharaan Sebuah perangkat lunak dapat mengalami perubahan ketika sudah dikirimkan ke user. Perubahan bisa terjadi karena adanya kesalahan yang muncul dan tidak terdeteksi saat pengujian atau terjadi

karena

perangkat

lunak

harus

beradaptasi

dengan

lingkungan baru. Tahap pendukung atau pemeliharaan dapat mengulangi proses pengembangan mulai dari analisis spesifikasi untuk perbuahan perangkat lunak yang sudah ada, tapi tidak untuk membuat perangkat lunak baru.

2.2.4

Pengujian Perangkat Lunak Sebuah perangkat lunak perlu dijaga kualitasnya bahwa kualitas bergantung kepada kepuasan pelanggan (customer). Kualitas perangkat lunak perlu dijaga untuk keperluan sebagai berikut:  Agar dapat “survive” bertahan hidup di dunia bisnis perangkat lunak  Dapat bersaing dengan perangkat lunak yang lain  Penting untuk pemasaran global (global marketing)  Mengektifkan biaya agar tidak banyak membuang perangkat lunak karena kegagalan pemasaran atau kegagalan produksi  Mempertahankan pelanggan (customer) dan meningkatkan keuntungan.


Sering perangkat lunak mengandung kesalahan (error) pada prosesproses tertentu pada saat perangkat lunak sudah berada di tangan user. Kesalahan-kesalahan (error) pada perangkat lunak ini sering disebut dengan “bug”. Untuk menghindari banyaknya bug maka diperlukan adanya pengujian perangkat lunak sebelum perangkat lunak diberikan ke pelanggan atau selama perangkat lunak masih terus dikembangkan. Adanya bug adalah suatu yang biasa, bahkan di sebuah perangkat lunak yang sudah besar dan terkenal pun biasanyan masih terdapat bug. Oleh karena itu tidak perlu merasa tersinggung atau bersedih jika masih ditemukan bug pada perangkat lunak yang dikembangkan. Yang bisa dilakukan pengembang perangkat lunak adalah meminimalisir bug dengan melakukan pengujian. Kelakukan perangkat lunak yang tidak sesuai dengan spesifikasi yang dibutuhkan bisa dianggap sebagai bug. Pengujian adalah salah satu set aktivitas yang direncanakan dan sistematis untuk menguji atau mengevaluasi kebenaran yang diinginkan (S & Shalahuddin, 2013). Aktivitas pengujian terdiri dati satu set atau sekumpulan langkah dimana dapat menempatkan desain kasus uji yang spesifik dan metode pengujian. Secara umum pola pengujian pada perangkat lunak adalah sebagi berikut : 

Pengujian dimulai dari level komponen hingga integrasi antar komponen menjadi sebuah sistem.



Teknik pengujian berbeda-beda sesuai dengan berbagai sisi atau unit uji dalam waktu yang berbeda-beda pula, bergantung pada pengujian pada bagian mana yang dibutuhkan.



Pengujian dilakukan oleh pengembang perangkat lunak, jika untuk proyek besar, pengujian bisa dilakukan oleh tim uji yang tidak terkait dengan tim pengembang perangkat lunak (Independent Test Group). Pengujian perangkat lunak adalah sebuah elemen sebuah topik

yang memiliki cakupan luas dan sering dikaitkan dengan verifikasi (verification) dan validasi (validation) (S & Shalahuddin, 2013). Verifikasi


mengacu pada sekumpulan aktivitas yang menjamin bahwa perangkat lunak mengimplementasikan dengan benar sebuah fungsi yang spesifik. Validasi mengacu pada sekumpulan aktivitas yang berbeda yang menjamin bahwa perangkat lunak yang dibangun dapat ditelusuri sesuai dengan kebutuhan pelanggan (customer). Dapat juga dikatakan sebagai berikut : 

Verifikasi : “Apakah produk yang dibangun dengan benar?” atau “apakah proses pengembangan produk sudah benar dan telah mengimplementasikan fungsi yang benar?”.



Validasi : “Apakah sudah membangun produk yang benar?” atau “Apakah hasil produk sudah sesuai dengan yang diinginkan?”.

2.2.5

Verifikasi dan Validasi Pengujian a.

Verifikasi Pengujian

Pengujian untuk verifikasi memiliki tahapan sebagai berikut :

Pengujian Unit

Pengujian Integrasi

Pengujian Sistem

Pengujian Penerimaan

Gambar 2.5 Pengujian Perangkat Lunak Pengujian diawali dari pengujian unit. Unit disini bisa berupa kumpulan fungsi atau prosedur yang memiliki keterkaitan pada pemrograman terstruktur atau class pada pemrograman berorientasi objek. Unit juga dapat berupa modul atau dikenal juga sebagai package. Setelah unit-unit selesai diuji maka dilakukan pengujian integrasi. Pengujian integrasi sebaiknya dilakukan secara bertahap, tidak dilakukan secara satu tahap langsung di akhir untuk menghindari kesulitan penelusuran jika terjadi kesalahan (error). Pengujian integrasi lebih pada pengujian penggabungan dari dua atau lebih unit pada perangkat lunak.


Setelah pengujian integrasi maka dilakukan pengujian sistem, yang dimana unit-unit proses yang sudah diintergrasikan akan diuji dengan antarmuka yang sudah dibuat sehingga pengujian ini dimaksudkan untuk menguji sistem perangkat lunak secara keseluruhan dan diuji secara satu sistem. Setelah pengujian sistem selesai maka dapat dilakukan pengujian penerimaan perangkat lunak oleh pelanggan (customer) atau pengguna (user). Pengujian penerimaan digunakan untuk mengetahui kepuasan pelanggan atau user terhadap perangkat lunak yang sudah dibuat. Jika pelanggan sudah puas dengan perangkat lunaknya, maka perangkat lunak tersebut dapat diserahkan kepada pelanggan (customer) b. Validasi Pengujian Pengujian untuk validasi memiliki beberapa pendekatan sebagai berikut : 

Black-Box Testing (pengujian kotak hitam) Pengujian kotak hitam menguji perangkat lunak dari segi spesifikasi fungsional tanpa menguji desain dan kode program. Pengujian dimaksudkan untuk mengetahui apakah fungsi-fungsi, masukan dan keluaran dari perangkat lunak tersebut sudah sesuai dengan spesifikasi yang dibutuhkan. Pengujian kotak hitam dilakukan dengan membuat kasus uji yang bersifat mencoba semua fungsi dengan memakai perangkat lunak sesuai dengan spesifikasi yang dibutuhkan. Kasus uji yang dibuat untuk melakukan pengujian kotak hitam harus dibuat dengan kasus benar dan kasus salah.



White-Box Testing (pengujian kota putih) Pengujian kotak putih menguji perangkat lunak dari segi desain dan kode program, apakah mampu menghasilkan fungsi-fungsi, masukan dan keluaran dari perangkat lunak tersebut sudah sesuai dengan spesifikasi yang dibutuhkan. Pengujian kotak putih dilakukan dengan memeriksa logika dari kode program. Pembuatan


kasus uji bisa mengikuti standar pengujian dari standar pemrograman yang seharusnya.

2.3.

Pemodelan UML (Unified Modeling Language) UML (Unified Modeling Language) adalah bahasa pemodelan untuk sistem atau perangkat lunak yang berparadigma berorientasi objek. Pemodelan (modeling) sesungguhnya digunakan untuk penyederhanaan permasalahan-permasalahan yang kompleks sedemikian rupa sehingga lebih mudah dipelajari dan dipahami (Nugroho, 2010). Pada perkembangan teknik pemrograman berorientasi objek, muncullah sebuah standarisasi bahasa pemodelan utuk pembangunan perangkat

lunak

yang

dibangun

dengen

menggunakan

teknik

pemrograman berorientasi objek, yaitu Unified Modeling Language (UML). UML muncul karena adanya kebutuhan pemodelan visual untuk menspesifikasikan, menggambarkan, membangun dan dokumentasi dari sistem perangkat lunak (S & Shalahuddin, 2013). UML merupakan bahasa visual untuk pemodelan dan komunikasi mengenai sebuah sistem dengan menggunakan diagram dan teks-teks pendukung. Pada UML versi 2.3 terdapat 13 macam diagram yang dikelompokan menjadi 3 kategori. Pembagian kategori dan macam-macam diagram tersbut dapat dilihat pada gambar dibawah.


Structure Diagrams

Behavior Diagrams

Interaction Diagrams

Class diagram

Use case diagram

Sequence diagram

Object diagram

Activity diagram

Commucation diagram

Component diagram

State machine diagram

Timing diagram

Composite structure diagram

Interaction overview diagram

Package diagram

Deployment diagram

Gambar 2.6 Diagram UML 2.3 Berikut ini penjelasan singkat dari pembagian kategori tersebut. 

Structure diagrams yaitu kumpulan diagram yang digunakan untuk menggambarkan suatu struktur statis dari sistem yang dimodelkan.



Behaviour diagrams yaitu kumpulan diagram yang digunakan untk menggambarkan kelakuan sistem atau rangkaian perubahan yang terjadi pada sebuah sistem.



Interaction diagrams yaitu kumpulan diagram yang digunakan untuk menggambarkan interaksi sistem dengan sistem lain maupun interaksi antar subsistem pada suatu sistem.

2.3.1

Use Case Diagram Use care diagram menggambarkan fungsionalitas yang diharapkan

dari sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan “bagaiman”. Sebuah use case merepresentasikan sebuah


interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, meng-create sebuah daftar belanja, dan sebagainya. Seorang / sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan-pekerjaan tertentu. Use case diagram dapat sangat membantu bila

kita

sedang

menyusun

requirement

sebuah

sistem,

mengkomunikasikan rancangan dengan klien, dan merancang test case untuk semua feature yang ada pada sistem (Yasin, 2012).

Gambar 2.7 Contoh Use case Diagram (Pressman, 2010) Tabel 2.1 Notasi Pada Use case Diagram (S & Shalahuddin, 2013, p. 156) Simbol

Deskripsi

Use case

Fungsionalitas

yang

disediakan

sistem sebagai unit-unit yang saling bertukar pesan antar unit atau aktor. Biasanya

dinyatakan

dengan

menggunakan kata kerja di awal frase nama use case. Aktor/actor

Orang, proses, atau sistem lain yang


berinteraksi

dengan

sistem

informasi yang akan dibuat di luar sistem informasi yang akan dibuat itu sendiri, simbol

sehingga

dari

aktor

walaupun itu

adalah

menyerupai gambar orang, tetapi aktor

tersebut

belum

tentu

merupakan orang. Asosiasi/association

Komunikasi

antara

aktor

yang

berpatisipasi pada use case atau use case memiliki interaksi dengan aktor. Relasi use case tambahan ke sebuah

Ektensi/extend

use case dimana use case yang ditambah tersebut dapat berdiri sendiri

walau

tanpa

use

case

tambahan tersebut. Seperti pada inheritance

prinsip

pada

pemrograman berorientasi objek, biasanya

use

case

tambahan

memiliki nama depan yang sama dengan use case yang ditambah. Generalisasi/generalization

Hubungan

generalisasi

dan

spesialisasi (umum – khusus) antara dua buah use case dimana fungsi yang satu adalah fungsi yang lebih umum dari yang lainnya. Include / Uses

Relasi use case tambahan ke sebuah use case dimana use case yang ditambahkan memerlukan use case ini untuk menjalankan fungsinya atau


sebagai

syarat

untuk

menjalankan use case tersebut. Setiap diagram use case akan dilengkapi dengan skenario. Skenario diagram use case adalah alur jalannya proses use case dari sisi aktor dan sistem. 2.3.2

Sequence Diagram Diagram sekuen menggambarkan kelalukan objek pada use case

dengan mendeskripsikan waktu hidup objek dan pesan yang dikirimkan dan diteriman antar objek. Oleh karena itu untuk menggambarkan diagram sekuan maka harus diketahui objek-objek yang dimiliki kelas yang menjadi objek tersebut. Membuat diagram sekuen diperlukan untuk mengiktui skenario yang ada pada diagram use case. Banyaknya diagram sekuen yang harus digambar adalah minimal sebanyak pendefinisan use case yang memiliki proses sendiri atau yang penting semua use case yang telah didefinisikan interaksi jalannya pesan sudah dicakup pada diagtam sekuen sehingga semakin banyak use case yang didefinisikan maka diagram sekuen yang harus dibuat juga semakin banyak. Tabel 2.2 Notasi Pada Sequence Diagram (S & Shalahuddin, 2013, p. 165)

Simbol

Deskripsi

Aktor / Actor

Orang, proses, atau sistem lain yang berinterkasi dengan sistem informasi yang akan dibuat di luar sistem

informasi

itu

sendiri.

Walaupun simbol dari aktor adalah gambar

Atau

orang,

merupakan


belum

orang.

tentu

Biasanya

dinyatakan

menggunakan

kata

benda di awal frase nama aktor.

Garis hidup / lifeline

Menyatakan

kehidupan

suatu

objek

yang

objek

Objek / Object

Menyatakan

berinteraksi pesan.

Waktu aktif / Active

Menyatakan objek dalam keadaan aktif dan berinteraksi, semua yang terhubung dengan waktu aktif ini adalah

sebuah

tahapan

yang

dilakukan di dalamnya. Pesan tipe create

Menyatakan suatu objek membuat objek

yang

lain,

arah

panah

mengarah pada objek yang dibuat. Pesan tipe call

Menyatakan

suatu

objek

memanggil operasi/metode yang ada pada obejk lain atau dirinya sendiri. Arah panah mengarah pada

objek

yang

memilik

operasi/metode, sehingga metode yang dipanggil harus ada pada diagram class sesuai dengan kelas


objek yang berinterkasi. Pesan tipe send

Menyatakan bahwa suatu objek mengirimkan data / masukan / informasi ke objek lainnya. Arah panah mengarah pada objek yang dikirimkan pesan.

Pesan tipe return

Menyatakan bahwa suatu onjek yang

telah

menjalankan

suatu

operasi atau metode menghasilkan suatu pengembalian pada objek tertentu, arah panah mengarah pada

objek

yang

menerima

kembalian. Pesan tipe destroy

Menyatakan

suatu

objek

mengakhiri hidup objek yang lain, arah panah mengarah pada objek yang diakhiri, sebaiknya jika ada create maka ada destroy

2.3.3

Activity Diagram Activity diagram menggambarkan rangkaian aliran dari aktivitas, digunakan untuk mendeskripsikan aktivitas yang dibentuk dalam suatu operasi sehingga dapat juga digunakan untuk aktivitas lainnya seperti use case atau interaksi (Yasin, 2012). Notasi yang digunakan dalam activity diagram adalah sebagai berikut: a) Activity Notasi yang menggambarkan pelaksanaan dari beberapa proses dalam aliran pekerjaan. b) Transition Notasi yang digunakan untuk memperlihatkan jalan aliran kontrol dari activity ke activity. 23 http://digilib.mercubuana.ac.id/

c) Decision Notasi yang menandakan kontrol cabang aliran berdasarkan decision point. d) Synchronization Bars Aliran kerja notasi ini menandakan bahwa beberapa aktivitas dapat diselesaikan secara bersamaan (paralel). Diagram aktivitas juga banyak digunakan untuk mendefinisikan hal-hal berikut: 

Rancangan proses bisnis dimana setiap uturan aktivitas yang digambarkan merupakan proses bisnis sistem yang didefinisikan.



Urutan atau pengelompokan tampilan dari sistem/user inteface dimana setiap aktivitas dianggap memiliki sebuah rancangan antarmuka tampilan.



Rancangan pengujian dimana setiap aktivitas dingaap memerlukan sebuah pengujian yang perlu didefinisikan kasus ujinya.



Rancangan menu yang ditampilkan pada perangkat lunak.


Gambar 2.8 Contoh Activity Diagram (Pressman, 2010)

Tabel 2.3 Notasi Pada Activity Diagram (S & Shalahuddin, 2013, p. 162)

Simbol

Deskripsi

Status awal / Start

Status awal aktivitas dari sebuah sistem.

Sebuah

diagram

aktivitas

memiliki sebuah status awal.

Aktivitas / Activity

Aktivitas yang dilakukan oleh suatu


sistem. Penamaan aktivitas biasanya diawali dengan kata kerja

Percabangan

Asosiasi percabangan dimana jika ada pilihan aktivitas lebih dari satu.

Penggabungan

Asosiasi

penggabungan

Asosiasi

penggabungan dimana lebih dari satu aktivitas digabungkan menjadi satu.

Status akhir / End

Status akhir yang dilakukan sistem. Sebuah diagram aktivitas memiliki status akhir.

Swimlane

Memisahkan organisasi bisni yang bertanggungg jawab terhadap aktivitas yang terjadi.


2.3.4

Class Diagram Class Diagram menggambarkan struktur dan deskripsi class, package, dan objek beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain. Class diagram berfungsi untuk menjelaskan tipe dari objek sistem dan hubungannya dengan objek yang lain. Objek adalah nilai tertentu dari setiap attribute kelas entity. Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah objek dan merupakan inti dari pengembangan berorientasi objek. Class menggambarkan keadaan (attribute/property) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metode/fungsi) (Yasin, 2012).

Gambar 2.9 Contoh Class Diagram (Pressman, 2010) Kelas memiliki apa yang disebut atribut dan metode. 

Atribut merupakan variabel-variabel yang dimikili oleh suatu kelas.



Operasi atau metode adalah fungsi-fungsi yang dimiliki oleh suatu kelas.


Tabel 2.4 Notasi Pada Class Diagram (S & Shalahuddin, 2013, p. 146) Simbol

Deskripsi

Kelas / class

Kelas pada struktur sistem.

Antarmuka / interface

Sama

dengan

dalam

pemrograman

konsep

interface

berorientasi

objek. Asosiasi / association

Relasi antarkelas dengan makna umum. Asosiasi biasanya disertai dengan multipicity.

Asosiasi

berarah

/

directed Relasi antar kelas dengan makna

association

kelas yang satu digunakan oleh kelas yang lain. Asosiasi biasanya juga disertai dengan multipicity.

Generalisasi

Relasi antar kelas dengan makna generalisasi – spesialiasi (umum khusus)

Kebergantungan / dependecy

Relasi antar kelas dengan makna kebergantungan antar kelas.

Agregasi / aggregation

Relasi antar kelas dengan makna semua – bagian (whole-part).


2.4 Android Android merupakan sebuah sistem operasi perangkat mobile berbasis linux yang mencakup sistem operasi, middleware, dan aplikasi (Supardi, 2011). Beberapa pengertian lain dari Android, yaitu:  Merupakan platform terbuka (open source) bagi para pengembang (Programmer) untuk membuat aplikasi.  Merupakan sistem operasi yang dibeli Google Inc. dari Android Inc.  Bukan

bahasa

pemrograman,

akan

tetapi

hanya

menyediakan lingkungan hidup atau run time environment yang disebut DVM (Dalvik Virtual Machine) yang telah dioptimasi untuk device / alat dengan sistem memori yang kecil. Untuk mengembangkan Android, dibentuk OHA (Open Handset Aliance), konsorium dari 34 perusahaan peranti keras (Hardware), peranti lunak (Software), dan telekomunikasi, termasuk Google, HTC, Intel, Motorola, Qualcomm, T-Mobile, dan Nvidia.

2.5 Java Java dalam ilmu komputer merupakan bahasa pemrograman berorientasi objek yang diperkenalkan pada tahun 1995 oleh Sun Microsystems, Inc yang saat diciptakan dipimpin oleh James Gosling. Java adalah bahasa pemrograman yang mirip dengan C/C++. Salah satu keunggulan dari Java adalah dapat berjalan dibanyak platform perangkat keras dan perangkat lunak sehingga pengembang aplikasi dan pemrogram dapat menuliskan program dengan Java (sekali dan hanya sekali saja) kemudian dengan relatif mudah bisa menjalankannya dimana saja, dengan istilah populernya adalah “Write Once, Run Anywhere”.


Java adalah bahasa pemrograman berorientasi objek serbaguna. Java menyediakan sejumlah perluasan yang mendukung aplikasi GUI (Graphical User Interface), pengembangan aplikasi client/server untuk jaringan lokal (LAN – Local Area Network) dan jaringan berskala luas (WAN – Wide Area Network) , serta yang terutama aplikasi internet. 2.6 JSON (Java Script Object Notation) JSON (Java Script Object Notation) adalah format pertukaran data yang bersifat ringan disusun oleh Douglas Crockford. Fokus JSON adalah pada representasi data di website. JSON dirancang untuk memudahkan pertukaran data pada situs dan merupakan perluasan dari fungsi-fungsi javascript. Penggunaan JSON Parsing dalam HTTP Connection ini bertujuan untuk memberi kemudahan bagi user ketika menggunakan aplikasi ini. Dengan adanya JSON Parsing dalam HTTP Connection, informasi yang ada didalam website dapat ditampilkan di dalam sebuah aplikasi mobile. Hal ini menyebabkan aplikasi mobile tidak perlu menampilkan seluruh konten yang ada didalam website seperti halnya pada mobile web browser. Aplikasi android akan memilih jenis konten yang ingin ditampilkan, seperti halnya gambar, item description, dan lain-lain.


BAB II LANDASAN TEORI

Recommend Documents