BAB 2 TINJAUAN PUSTAKA. Tabel 2.1 Jenis-jenis UML Versi 2.0 Requirement Analysis Logical Design Phase

BAB 2 TINJAUAN PUSTAKA

2.1

Unified Modeling Language Unified Modeling Language (UML) adalah satu set model konvensi yang

digunakan untuk menentukan atau menggambarkan sebuah sistem perangkat lunak sebagai sebuah objek (Whitten & Bentley, 2007:371). Menurut Whitten dan Bentley (2007:381), UML dibagi menjadi tiga jenis seperti yang tertera pada Tabel 2.1.

Tabel 2.1 Jenis-jenis UML Versi 2.0 Requirement Analysis

Logical Design

Phase

Phase

Use-case Diagrams

Activity Diagrams System Sequence Diagrams Class Diagrams

Physical Design Phase Sequence Diagrams Class Diagrams State Machine Diagrams Communication Diagrams Component Diagrams Deployement Diagrams

2.1.1 Use Case Diagram Use case modeling merupakan pengidentifikasi dan penggambaran fungsi sistem dengan menggunakan alat yang bernama use case. Use case digunakan untuk menggambarkan fungsi sistem dari perspektif pengguna luar dengan terminologi yang mudah dimengerti. Agar maksud yang ingin disampaikan dapat disampaikan dengan akurat, maka pengguna luar juga diturut serta sebagai bahan dan subjek ahli yang memiliki pengetahuan tentang proses bisnis atau kegiatan. Menurut Whitten dan Bentley (2007:246-256), terdapat unsur-unsur penting dalam Use Case Diagram, yaitu: 1.

Use Case

7

8 Use case digambarkan dengan bentuk bulatan panjang dengan label nama use case yang terletak diatas, dibawah atau didalam bulatan panjang. Use case mewakili tujuan sebuah sistem dan menggambarkan urutan aktivitas dan interaksi pengguna yang ingin mencapai suatu tujuan. Pembuatan use case telah terbukti sebagai teknik yang luar biasa untuk pengertiannya mengenai kebutuhan yang ada. Use case tidak dianggap sebagai kebutuhan fungsional, tetapi sebagai cerita/skenario, dengan cerita yang terdiri dari satu atau banyak kebutuhan.

Gambar 2.1 Contoh Use Case Diagram Sederhana (Sumber: Whitten & Bentley, 2007:246)

Use case pada awalnya didefinisikan selama persyaratan tahapan awal perancangan dan ditambahkan sepanjang perancangan. Selama persyaratan awal, use case digunakan untuk menangkap maksud penting dari permasalahan bisnis dan untuk memodelkan fungsi dari sistem yang diusulkan. Selain itu, use case menjadi titik awal untuk mengidentifikasi entitas data atau objek dari sistem. Selama analisis kebutuhan, use case digunakan untuk model penggunaan sistem secara lebih detil. Dengan kata lain, use case diperbaru untuk menentukan keinginan pengguna. Use case dapat membantu dalam pendefinisian setiap prototipe atau tampilan antarmuka. Use case juga membantu dalam mengidentifikasi objek atau perilaku sistem dan dalam merancang antarmuka dan kode spesifikasi, serta berfungsi sebagai rencana untuk menguji sistem.

9 Pada saat pengembangan sistem, use case membantu pengembang dalam pemrograman dan pengujian. Selain itu, use case juga berguna sebagai alat untuk berkomunikasi kepada setiap jenis pengguna dan dokumentasi sistem. Use case juga dapat berfungsi sebagai alat pada saat pelatihan. Use case mengandung informasi fungsi sistem secara detil. Oleh karena itu, use case digunakan sebagai acuan untuk memvalidasi sistem.

2.

Actor Use case diawali atau dipicu oleh pengguna eksternal yang disebut aktor. Seorang aktor memicu aktivitas pada sistem untuk menyelesaikan beberapa tugas bisnis yang akan menghasilkan sesuatu yang bernilai dan dapat diukur. Aktor pada use case tidak selalu mengacu kepada manusia, tetapi juga dapat sebagai organisasi, sistem informasi, alat luar, seperti sensor panas, atau konsep waktu. Seorang aktor diwakili secara grafis dengan stick man yang dilabeli nama peran yang dimainkan aktor. Aktor dibagi menjadi empat tipe, yaitu: a.

Primary business actor Primary business actor adalah stakeholder yang merasakan manfaat utama dari pelaksanaan use case dengan menerima suatu nilai yang dapat diukur atau diamati. Aktor utama dapat memicu sebuah kejadian maupun tidak memicu sama sekali. Sebagai contoh, di dalam sebuah kejadian bisnis, seorang pegawai menerima pembayaran dari sistem gaji setiap hari Jumat. Pada contoh ini, karyawan tidak memicu terjadinya sebuah kejadian, tetapi pegawai tetap sebagai penerima utama yang mempunyai nilai terukur. Aktor bisnis utama dan aktor sistem primer dalam sebuah kejadian dapat berupa pihak yang sama, yang pelaku bisnis utama melakukan interaksi langsung ke dalam sistem. Contohnya seseorang menyewa mobil melalui sebuah situs.

10

b. Primary system actor Primary system actor adalah stakeholder yang berinteraksi secara langsung dengan sistem untuk memulai atau memicu sebuah kejadian. Aktor jenis ini dapat berinteraksi dengan pelaku bisnis utama untuk mencapai tujuan melalui sistem dan juga memfasilitasi kejadian langsung melalui penggunaan sistem untuk kepentingan pelaku bisnis utama. Contohnya adalah pegawai toko yang menggunakan fungsi scan barang, yang terdiri dari pelanggan yang membeli, operator telepon yang memberikan bantuan untuk pelanggan, dan pegawai bank yang memproses transaksi perbankan. c.

External server actor External server actor adalah stakeholder yang merespons permintaan dari use case. Contohnya adalah biro kredit otorisasi pengisian dengan kartu kredit.

d. External receiver actor External receiver actor adalah stakeholder yang menerima suatu nilai yang dapat dihitung atau diamati (output) dari use case walaupun bukan merupakan aktor utama. Sebagai contoh, sebuah gudang menerima perintah untuk mempersiapkan pengiriman setelah pelanggan memesan benda.

Gambar 2.2 Contoh Actor Dalam Use Case (Sumber: Whitten & Bentley, 2007:246)

3.

Relationship Relationship dapat digambarkan sebagai garis antar dua simbol utama pada diagram use case. Arti dari hubungan garis tersebut dapat

11 berbeda-beda tergantung dari garis yang digambarkan dan jenis simbol yang terhubung. a.

Association Association (asosiasi) merupakan hubungan antara aktor dan use case yang digunakan untuk menggambarkan interaksi diantaranya. Asosiasi digambarkan sebagai garis utuh yang menghubungkan aktor dan use case. Sebuah asosiasi yang menunjuk arah panah ke use case lainnya mengindikasikan bahwa use case tersebut ditiru oleh aktor. Asosiasi tanpa panah ini menunjukkan interaksi antara use case dan external server atau receiver actor. Ketika aktor berasosiasi dengan use case, dapat dikatakan bahwa aktor berkomunikasi dengan use case. Asosiasi bisa saja bidirectional atau undirectional.

Gambar 2.3 Contoh Penggunaan Association pada Use Case (Sumber: Whitten & Bentley, 2007:248)

b. Extends Sebuah use case bisa saja mempunyai fungsi kompleks yang terdiri dari beberapa langkah, yang mempersulit untuk memahami use case tersebut. Untuk menyederhanakan use case dan membuatnya lebih mudah dipahami, langkah-langkah yang lebih kompleks diturunkan pada penggunaan use case. Sebagai hasilnya, use case tersebut disebut sebagai extension use case, yang fungsinya didapat dari hasil penurunan use case sumber. Hubungan dari extension use case dan use case turunannya disebut dengan extends relationship. Sebuah use case dapat mempunyai extends relationship, tetapi use case tersebut hanya dapat dipanggil hanya oleh use case turunannya. Contohnya dapat

12 dilihat pada gambar di bawah. Pada gambar di bawah, extends relationship diberi label <<extends>>.

Gambar 2.4 Contoh Penggunaan Extends pada Use Case (Sumber: Whitten & Bentley, 2007:249)

c.

Uses (or Includes) Pada pembuatan diagram use case, sangat umum ditemukan sebuah use case yang mempunyai fungsi yang mirip. Hal tersebut lebih baik dipisahkan, dan pembuatan sebuah use case abstrak digunakan untuk mewakili suatu fungsi yang mirip. Sebuah use case abstrak dapat digunakan berkali-kali, dan hal ini menjadi alat yang luar biasa dalam mengurangi redundansi pada use case. Sebuah use case abstrak dapat digunakan oleh use case lainnya dengan bebas apabila use case tersebut membutuhkan fungsi yang terdapat dari use case abstrak. Hubungan antara use case abstrak dan use case yang menggunakan fungsinya disebut dengan uses relationship atau bisa disebut juga includes. Garis penghubung antar use case pada jenis uses diwakili oleh label <<uses>> atau <> untuk menunjukkan relasi ini.

13

Gambar 2.5 Contoh Penggunaan Includes pada Use Case (Sumber: Whitten & Bentley, 2007:249)

d. Depends On Project manager atau pemimpin pengembangan memerlukan pengetahuan untuk mengetahui jenis dependensi use case agar dapat memutuskan urutan use case yang dirancang. Sebagai contoh, use case penarikan uang tidak bisa dilaksanakan apabila use case deposit belum pernah dilaksanakan, dan suatu tindakan tidak dapat dilakukan sebelum mendaftarkan diri ke bank. Dikarenakan adanya urutan tersebut, tim pengembang dapat merancang tindakantindakan yang dapat dipilih untuk mengembangkan use case, yang harus memenuhi syarat terlebih dahulu seperti mendaftarkan diri ke bank, deposit uang, kemudian penarikan uang sebagai pengujian. Diagram use case yang digunakan untuk memodelkan sebuah sistem berjalan sangat dibantu dengan hal ini karena hal ini memudahkan perencanaan dan penjadwalan terhadap tujuan. Garis penghubung antar use case pada jenis depends on diwakili oleh label <<depends on>>.

14

Gambar 2.6 Contoh Penggunaan Depends On pada Use Case (Sumber: Whitten & Bentley, 2007:250)

e.

Inheritance Ketika dua atau lebih aktor berbagi fungsi yang sama, dapat dikatakan bahwa mereka memanggil sebuah kejadian yang sama. Untuk menyederhanakan hal tersebut, maka lebih baik dibuat suatu aktor sebagai perwakilan untuk mengurangi komunikasi yang redundan dengan sistem. Contohnya, anggota perpustakaan yang mempunyai kartu keanggotan mempunyai wewenang untuk mencari buku yang tersedia. Selain itu, anggota tersebut juga dapat meminjam buku dari perpustakaan. Dikarenakan perpustakaan merupakan

sebuah

institusi

publik,

maka

pengunjung

diperbolehkan untuk menggunakan layanan untuk mencari buku yang tersedia. Akan

tetapi,

pengunjung

tidak

diperbolehkan

untuk

meminjam buku, karena wewenang tersebut dikhususkan untuk anggota perpustakaan. Dengan menciptakan sebuah aktor abstrak bernama pelanggan, maka fungsi yang sama dapat diturunkan ke anggota dan pengunjung untuk mengurangi redundansi.

15

Gambar 2.7 Contoh Penggunaan Inheritance pada Use Case (Sumber: Whitten & Bentley, 2007:250)

Gambar 2.8 Contoh Use Case Diagram (Sumber: Whitten & Bentley, 2007:256)

2.1.2 Use Case Narrative Use Case Narrative adalah deskripsi berupa teks dari sebuah kejadian dan cara pengguna berinteraksi dengan sistem untuk menyelesaikan sebuah tugas (Whitten & Bentley, 2007:256-260).

16

Gambar 2.9 Contoh Use Case Narrative (Sumber: Whitten & Bentley, 2007:257)

Bagian-bagian use case narrative yang menggambarkan sebuah peristiwa mencakup hal-hal berikut: a.

Author, nama dari individu yang melakukan kontribusi dalam penulisan use case.

b.

Date, tanggal terakhir use case diubah.

c.

Version, versi yang digunakan dalam use case.

d.

Use-case name, nama yang mewakili tujuan yang ingin dicapai dalam use case dan diawali dengan kata kerja.

e.

Use-case type, persyaratan bisnis untuk use case yang berfokus pada visi strategis dan tujuan dari stakeholder; jenis use case ini tidak membahas masalah detil teknis, melainkan orientasi bisnis dan pandangan dari perilaku yang diinginkan dari sebuah sistem.

f.

Use-case ID, identifikasi unik yang mewakili use case.

g.

Priority, nilai prioritas yang mengindikasikan pentingnya use case tersebut dalam sebuah sistem.

h.

Source, entitas yang memicu pembuatan use case yang dapat berupa kebutuhan, dokumen spesifik, atau stakeholder.

i.

Primary business actor, stakeholder yang mendapatkan manfaat utama dari eksekusi sebuah use case dengan menerima suatu nilai yang dapat dihitung atau diamati.

j.

Other participating actor, aktor lain yang turut berpartisipasi untuk mencapai tujuan dari use case.

17 k.

Interested stakeholder, individu yang mempunyai kepentingan di dalam pengembangan dan operasi dari sistem perangkat lunak.

l.

Description, deskripsi singkat yang terdiri dari beberapa kalimat untuk menjelaskan tujuan dari use case dan aktivitasnya.

Setiap high-level use case harus diperluas dengan adanya use case typical course of events dan alternator courses. Use case typical course of events merupakan deskripsi mengenai langkah demi langkah yang diawali dengan interaksi aktor dengan use case dan berlanjut sampai akhir sebuah kejadian. Alternate

courses

mendokumentasikan

segala

pengecualian

ataupun

percabangan bersyarat dari use case.

Gambar 2.10 Contoh Use Case Narrative yang Telah Diperluas (Sumber: Whitten & Bentley, 2007:259)

18

Gambar 2.11 Lanjutan Use Case Narrative yang Telah Diperluas (Sumber: Whitten & Bentley, 2007:260)

Bagian-bagian use case narrative yang diperluas mencakup hal-hal berikut: a) Precondition, sebuah pembatas pada sistem sebelum use case dapat dijalankan. Pada khususnya, hal ini mengacu pada use case lainnya yang harus dijalankan terlebih dahulu. b) Trigger, peristiwa yang memulai pelaksanaan sebuah use case. Biasa berupa tindakan fisik seperti seorang pelanggan yang masuk ke dalam toko atau seseorang yang memeriksa kotak surat. c) Typical course of events, sebuah rangkaian aktivitas yang biasa dilakukan oleh aktor dan/atau sistem agar mencapai tujuan dari sebuah use case. Hal ini termasuk interaksi antara sistem dengan aktor dan aktivitas yang dijalankan oleh sistem untuk merespons terhadap setiap interaksi. d) Alternate courses, pendokumentasian terhadap tingkah laku sebuah use case apabila terjadi pengecualian atau variasi pada jalur yang biasa. e) Conclusion, menentukan waktu sebuah use case berhenti. f)

Postcondition, sebuah pembatas pada sistem sesudah use case dijalankan. Pada khususnya, hal ini mengacu pada use case lainnya yang harus dijalankan terlebih dahulu.

g) Business rules, menentukan kebijakan dan prosedur bisnis yang harus dipatuhi sistem baru. Hal ini dapat termasuk perhitungan biaya pengiriman ataupun peraturan untuk mendapatkan syarat kredit.

19 h) Implementation constraints and specifications, menentukan setiap persyaratan nonfungsional yang dapat berdampak pada realisasi use case dan berguna dalam setiap perencanaan dan cakupan arsitektural. i)

Assumptions, semua asumsi yang dibuat ketika mendokumentasikan use case.

j)

Open issues, setiap pertanyaan atau persoalan yang harus diselesaikan atau diteliti sebelum use case dapat diselesaikan.

2.1.3 Class Responsible Collaboration Class Responsible Collaboration (CRC) merupakan sekumpulan kartu yang berisi mengenai penjelasan perilaku use case dan tanggung jawab yang telah dikaitkan dengan suatu class. CRC dikembangkan dan disempurnakan dengan menggunakan proses interaktif, dan kartu CRC dibagi kepada kelompok analis sistem atau pengguna. Proses ini dimulai dengan kartu dari kelas yang awalnya bertanggung jawab atas skenario. Kelas itu menjelaskan logika yang dibutuhkan untuk memenuhi tanggung jawab. Jika kelas tersebut membutuhkan informasi, maka tidak harus memiliki atau mengubah informasi yang ada.

Gambar 2.12 Contoh Kartu CRC (Sumber: Whitten & Bentley, 2007:658)

2.1.4 Class Diagram Menurut

Whitten

dan

Bentley

(2007:382),

class

diagram

menggambarkan struktur dari suatu objek pada sistem dan menunjukkan hubungan antar kelas objek dalam sistem tersebut. Berikut penjelasan mengenai hubungan pada class diagram:

20 1.

Multiplicity Multiplicity adalah kemunculan satu kelas objek dari kejadian tunggal pada objek terkait yang diwakili oleh simbol-simbol untuk menunjukan jenis hubungan antar class.

Gambar 2.13 Multiplicity pada Class Diagram (Sumber: Whitten & Bentley, 2007:377)

2.

Association Association adalah hubungan antar satu kelas dengan kelas lainnya di dalam class diagram. Pada setiap association terdapat multiplicity dan umumnya merupakan hubungan bidirectional. Dengan kata lain, dapat ditafsirkan sebagai hubungan dua arah.

3.

Aggregation

21 Aggregation adalah hubungan ketika kelas A, yang lebih besar, berisi satu atau lebih bagian kecil dari kelas B, tetapi tidak memiliki hubungan erat, sehingga kelas A tetap bisa berdiri sendiri tanpa kehadiran kelas B. Pada versi UML 2.0 notasi aggregation tidak digunakan lagi karena fungsinya yang serupa dengan association.

Gambar 2.14 Aggregation pada Class Diagram (Sumber: Whitten & Bentley, 2007:379)

4.

Composition Composition adalah aggregation yang hubungan antar kelas berkaitan erat. Hal ini dikarenakan hubungan yang tercipta bertanggung jawab untuk penciptaan dan penghancuran dari bagian keseluruhan. Dengan kata lain, apabila kelas utamanya tidak aktif, maka bagiannya akan ikut tidak aktif bersama dengan kelas itu, dan sebaliknya.

Gambar 2.15 Composition pada Class Diagram (Sumber: Whitten & Bentley, 2007:379)

5.

Generalization/specialization Generalisasi/spesialisasi adalah sebuah kelas (supertype) yang memiliki atribut dan perilaku yang umum yang telah dikelompokkan.

22 Atribut dan metode dari kelas objek supertype kemudian diwariskan ke kelas objek (subtype).

Gambar 2.16 Generalization/specialization pada Class Diagram (Sumber: Whitten & Bentley, 2007:376)

2.1.5 Activity Diagram Activity Diagram adalah diagram yang digunakan untuk menggambarkan urutan proses bisnis, use case, atau logika dari perilaku sebuah objek. (Whitten & Bentley, 2007:390). Menurut Whitten dan Bentley (2007:391), dalam Activity

Diagram

terdapat

beberapa

simbol

yang

digunakan

untuk

menerangkan alur di dalam sistem, seperti yang tertera pada tabel berikut:

Tabel 2.2 Simbol pada Activity Diagram Simbol

Nama

Deskripsi

Initial Node Mewakili awal dari suatu proses Actions

Flow

Mewakili langkah-langkah proses dalam sistem Mewakili arah tujuan dari proses yang terkadang dilengkapi dengan kata jika berasal

23 Simbol

Nama

Deskripsi dari decision. Mewakili pilihan yang memiliki dua atau

Decision

lebih arah flow keluar Mewakili penyatuan flow yang terpisah oleh

Merge

decision Mewakili notasi dengan satu flow masuk

Fork

dimana terdapat dua atau lebih flow keluar yang berjalan sacara bersamaan. Mewakili notasi dengan dua atau lebih flow

Join

masuk dimana terdapat hanya satu flow keluar.

Activity Final

Mewakili akhir dari suatu proses

24

Gambar 2.17 Contoh Activity Diagram (Sumber: Whitten & Bentley, 2007:393)

2.1.6 Sequence Diagram Menurut Whitten dan Bentley (2007:660), Sequence Diagram dapat diartikan sebagai cara untuk mengintegrasikan langkah-langkah secara bertahap dari use case dengan objek dari Class Diagram. Hal ini dapat digunakan sebagai alat komunikasi dengan programmer untuk menentukan perilaku yang ingin diimplementasikan ke dalam use case. Urutan notasi pada Sequence Diagram dijelaskan pada tabel 2.3.

Tabel 2.3 Simbol pada Sequence Diagram Simbol

Nama

Deskripsi

25

Actor

<>

<

Interface class

Controller class

Pelaku yang berinteraksi dengan sistem.

Suatu notasi pada class interface agar tidak terjadi kebingungan antar jenis class biasa dengan interface. Setiap use case bisa mempunyai satu atau lebih controller yang digambarkan sama dengan notasi interface class.

Entity

Simbol yang mewakili class pada

Classes

Sequence Diagram.

Message

Simbol yang menunjukkan input pesan yang dikirim dari kelas ke kelas lainnya.

Activation

Simbol yang mengindikasikan waktu

Bars

periode hidup pada suatu kelas.

Return

Setiap behavior harus mengembalikan

Messages

pesan.

Self-call

Simbol yang mewakili sebuah objek yang memangil fungsinya sendiri. Sebuah simbol yang menunjukan area

Frame

yang membutuhkan perulangan, dan seleksi khusus.

26

Gambar 2.18 Contoh Sequence Diagram (Sumber: Whitten & Bentley, 2007:659)

2.2

Rekayasa Perangkat Lunak Menurut Sommerville (2011:7-8), rekayasa perangkat lunak adalah disiplin

teknik yang berkaitan dengan semua aspek produksi perangkat lunak dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah sistem tersebut digunakan. Ada dua frasa yang merupakan kunci penting dalam rekayasa perangkat lunak, yaitu: 1. Implementasi teori, metode, dan alat-alat yang tepat untuk digunakan dalam pengembangan dalam menyelesaikan masalah apapun yang terkait dengan pengembangan perangkat lunak. 2. Semua aspek produksi perangkat lunak, yang tidak hanya berkaitan dengan proses teknis dari pengembangan, tetapi juga mencakup kegiatan manajemen proyek dan pengembangan alat, metode, serta teori untuk mendukung sebuah produksi perangkat lunak.

2.3

Agile Software Programming Menurut Sommerville (2011:631), Agile Software Programming adalah

pendekatan iteratif yang perangkat lunak dikembangkan dan disampaikan kepada pelanggan secara bertahap. Pada metode ini, perencanaan terhadap fungsionalitas tidak dilakukan pada tahap awal, melainkan akan diputuskan selama proses pengembangan. Keputusan tentang hal yang harus disertakan dalam setiap inkremen tergantung pada perkembangan aplikasi dan prioritas pengguna. Argumentasi dalam pendekatan ini adalah bahwa prioritas pelanggan dan

27 kebutuhan dapat berubah sehingga merupakan sesuatu yang masuk akal untuk memiliki rencana yang fleksibel agar dapat mengikuti perubahan ini.

Gambar 2.19 Agile Programming (Sumber: Sommerville, 2011:632)

2.3.1 Extreme Programming Menurut Pressman dan Maxim (2015:72-75), Extreme Programming (XP) adalah metode perancangan yang menggunakan pendekatan berorientasi objek sebagai paradigma pembangunan yang disukai dan seperangkat aturan dan praktik yang terjadi di dalam empat konteks kegiatan kerangka yang mencakup planning, design, coding, dan testing. Metode Extreme Programming (XP) yang digunakan meliputi empat kegiatan pengembangan sebagai berikut: 1.

Planning Aktivitas perencanaan dimulai dari listening. Listening adalah aktivitas mengumpulkan kebutuhan yang memungkinkan anggota teknik dalam tim XP untuk mengerti isi konteks bisnis untuk menentukan fitur dan fungsi yang akan dikembangkan pada software. Proses listening mengarah pada pembuatan separangkat stories yang menggambarkan output, fitur, dan fungsi yang digunakan untuk membangun software. Pelanggan dan pengembang bekerja sama untuk menentukan bagaimana mengelompokkan stories ke dalam rilis berikutnya. Ketika stories yang dibuat telah disetujui, tim XP mengatur stories yang akan dikembangkan ke dalam salah satu dari tiga cara: (1) semua stories akan diimplementasikan secepatnya, (2) stories yang bernilai paling tinggi akan dijadwalkan dan diimplementasikan terlebih dahulu, atau (3) stories yang paling beresiko akan dijadwalkan dan diimplementasikan terlebih dahulu.

2.

Designing

28 Desain Extreme Programming (XP) mengikuti prinsip KIS (keep it simple) dengan ketat. Sebuah desain sederhana akan selalu lebih diutamakan dibanding dengan desain yang kompleks. Sebagai tambahan, desain menyediakan bimbingan implementasi pada stories. XP mendorong penggunaan kartu CRC (class-responsibility-collaborator) sebagai mekanisme efektif untuk memikirkan software sebagai konteks yang berorientasi objek. Kartu CRC mengidentifikasi dan mengatur kelas-kelas objek yang relevan pada penambahan software saat ini. Kartu CRC hanya satu-satunya produk desain yang dibuat sebagai proses dalam XP. XP mendukung penggunaan refactoring. Refactoring sendiri mempunyai arti bahwa desain terjadi baik sebelum dan setelah koding dimulai. Refactoring berarti proses desain terjadi terus menerus pada saat sistem sedang dibangun. Hal ini dapat memperkecil kemungkinan terjadinya bug pada saat peluncuran aplikasi. 3.

Coding Setelah kumpulan stories dikembangkan dan desain awal telah selesai, tim akan mengembangkan sebuah rangkaian satuan tes untuk setiap stories yang akan dimasukkan kedalam rilis terbaru. Setelah satuan tes selesai dibuat, pengembang berfokus pada apa yang harus diimplementasikan untuk melewati tes. Tes dilakukan apabila kode selesai dibuat dan hasil umpan balik didapatkan secara langsung yang kemudian akan diberikan kepada pengembang. Pair programming merupakan konsep kunci pada saat melakukan aktivitas coding di Extreme Programing (XP). Extreme Progamming (XP) merekomendasikan dua orang untuk bekerja bersama untuk membuat kode untuk sebuah stories. Hal ini menyediakan mekanisme untuk penyelesaian masalah secara real-time (dua pikiran biasanya lebih baik daripada satu) dan asuransi kualitas secara real-time. Pair programming juga menjaga pengembang untuk berfokus pada masalah yang ada. Pada saat pasangan pengembang menyelesaikan pekerjaannya, kode yang dikembangkan akan diintegrasi dengan pekerjaan pengembang lain. Pada beberapa kasus, integrasi dilakukan setiap hari oleh tim integrasi. Pada kasus lainnya, integrasi dilakukan oleh pasangan

29 pengembang yang bertanggung jawab. Hal ini membantu untuk menghindari masalah kompatibilitas dan tampilan secara dini. 4.

Testing Tes unit yang telah dibuat harus diimplementasi menggunakan framework yang memungkinkan suatu aplikasi dapat dites secara otomatis. Tes unit diatur kedalam universal testing suite, dimana tes integrasi dan validasi pada sistem dapat terjadi setiap hari. Hal ini akan membantu tim XP untuk mendapatkan hasil secara terus-menerus dan memberikan peringatan lebih awal apabila terjadi hal-hal yang tidak diinginkan. Pada bagian ini terdapat tes penerimaan yang dilakukan oleh klien mengenai keseluruhan fitur dan fungsionalitas sistem. Tes penerimaan didasari kebutuhan pengguna yang telah diimplementasikan sebagai bagian dari rilis software.

2.4

Interaksi Manusia dan Komputer Menurut Shneiderman dan Plaisant (2010:22), ilmu desain interaksi manusia

dengan komputer dimulai dengan menggabungkan metode pengumpulan data dan kerangka psikologi intelektual eksperimental untuk merancang tampilan antarmuka. Ilmu desain interaksi manusia mempelajari hubungan interaktif antara manusia dengan komputer yang dipengaruhi beberapa indikator, antara lainnya adalah alat yang digunakan, persepsi, lokasi, suara, dan sebagainya (Shneiderman & Plaisant, 2010: 40-43).

2.4.1 Lima Faktor Manusia Terukur Menurut Shneiderman dan Plaisant (2010:32), terdapat lima faktor manusia terukur yang digunakan untuk perancangan tampilan antarmuka, yaitu: 1.

Time to learn Lama waktu yang dibutuhkan untuk mempelajari tampilan antarmuka yang akan digunakan untuk menyelesaikan tugas tertentu.

2.

Speed of performance Lama waktu yang dibutuhkan pengguna untuk menyelesaikan sebuah tugas.

3.

Rate of errors by users

30 Seberapa banyak kesalahan yang dilakukan pengguna dalam kurun waktu tertentu dan jenis-jenis kesalahan yang dilakukan dalam menyelesaikan tugas tertentu. Pengendalian kesalahan adalah salah satu komponen penting dalam tampilan antarmuka. 4.

Retention over time Lama ingatan pengguna yang dapat bertahan ketika menggunakan tampilan antarmuka.

5.

Subjective Satisfaction Kepuasan pengguna terhadap rancangan tampilan antarmuka terhadap aspek-aspek yang ditawarkan.

2.4.2 Delapan Aturan Emas Desain Antarmuka Menurut Shneiderman dan Plaisant (2010:88-89), Interaksi Manusia dan Komputer mempunyai delapan aturan dasar yang menjadi panduan untuk merancang desain antarmuka, yaitu: 1.

Strive for consistency Urutan tindakan harus konsisten dalam situasi yang sama; terminologi yang sama harus digunakan dalam prompt, menu, dan layar bantuan; dan konsistensi warna, tata letak, penggunaan huruf kapital, jenis tulisan, dan lainnya harus digunakan secara menyeluruh. Pengecualian seperti konfirmasi yang diperlukan dari perintah hapus atau tidak adanya gema password harus jelas dan terbatas.

2.

Cater to universal usability Mengenali kebutuhan pengguna yang beragam dan membuat desain yang dinamis, memfasilitasi perubahan konten. Perbedaan antara pemula dan ahli, rentang umur, disabilitas, dan keberagaman teknologi masingmasing memperkaya spektrum persyaratan yang memandu proses desain. Menambahkan fitur kepada pemula, seperti penjelasan, dan fitur untuk ahli, seperti shortcut dan kecepatan yang cepat, dapat memperbagus desain antarmuka dan meningkatkan kualitas sistem.

3.

Offer informative feedback Untuk setiap aksi pengguna, sistem harus memberikan umpan balik. Untuk aksi-aksi yang sering dilakukan dan aksi-aksi minor, respons dapat ditampilkan secara sederhana sedangkan untuk aksi-aksi yang jarang

31 dilakukan dan aksi major, respons harus bersifat lebih substansial. Presentasi visual dari sebuah objek menyediakan lingkungan yang nyaman untuk menampilkan perubahan secara eksplisit. 4.

Design dialogs to yield closure Urutan aksi harus dikelompokkan menjadi awal, tengah, dan akhir. Umpan balik yang informatif pada kelompok aksi akhir akan memberikan operator sebuah kepuasan atas pencapaian tersebut, rasa lega, dan sinyal untuk menjatuhkan rencana kontingensi dari pikiran mereka, dan sebuah indikator untuk mempersiapkan diri untuk kelompok aksi berikutnya. Sebagi contoh, situs e-commerce menggerakkan pengguna dari memilih produk sampai pada saat checkout, diakhiri dengan halaman konfirmasi yang jelas menandakan selesainya transaksi dilakukan.

5.

Prevent errors Sebisa mungkin, sistem harus dirancang agar para pengguna tidak dapat melakukan kesalahan yang serius; contohnya, menggelapkan menu yang tidak sesuai dan tidak memperbolehkan alfabet di kolom numerik. Jika pengguna membuat sebuah kesalahan, antarmuka harus dapat mendeteksi kesalahan

tersebut dan

menyediakan

instruksi

yang

sederhana,

membangun, dan spesifik untuk membalikkan keadaan tersebut. 6.

Permit easy reversal of actions Diusahakan agar aksi-aksi dapat dibalikkan. Fitur ini dapat mengurangi sikap cemas pengguna karena mereka tahu bahwa sebuah kesalahan dapat dibalikkan, dan mendorong para pengguna untuk menjelajahi pilihan-pilihan yang tidak lazim.

7.

Support internal locus of control Pengguna yang berpengalaman memiliki keingininan yang kuat untuk merasa bahwa mereka yang mengendalikan antarmuka dan antarmuka tersebut merespons terhadap aksi yang dilakukan mereka.

8.

Reduce short-term memory load Keterbatasan manusia dalam mengolah informasi untuk jangka pendek mengharuskan

para

perancang

menghindari

antarmuka

yang

penggunanya harus mengingat beberapa informasi dalam satu layar dan menggunakannya pada layar lain.

32

2.5

Bus Rapid Transit Menurut Siedler (2014:110-111), Bus Rapid Transit (BRT) adalah

kendaraan transit yang terdiri dari stasiun, kendaraan, jasa, jalur, dan elemen Intelligent Transportation System (ITS) yang terintegrasi dengan citra dan identitas positif yang kuat. Aplikasi BRT dirancang agar sesuai dengan pasar dan lingkungan fisik yang dapat secara bertahap diimplementasikan dalam berbagai lingkungan. Singkatnya, BRT adalah sistem yang terintegrasi secara permanen. Sistem tersebut terdiri dari pelayanan dan fasilitas yang secara kolektif meningkatkan kecepatan, keandalan, dan identitas bus transit. BRT mempunyai beberapa karakteristik utama, yaitu: 1. Roadways Kendaraan harus dapat beroperasi di semua jenis lalu lintas, tetapi penyediaan jalur sendiri akan meningkatkan kecepatan, keandalan, dan identitas. 2. Stations Stasiun-stasiun BRT menyerupai stasiun bus reguler dan memiliki desain yang mudah dikenali. 3. Rolling Stock Kendaraan BRT dirancang untuk meningkatkan kenyamanan, kecepatan, serta keamanan. BRT memiliki desain, warna, dan grafis yang khas agar mudah untuk dikenali. 4. Service Sistem layanan menawarkan penawaran yang cepat, teratur, dan layanan yang dapat diandalkan. 5. Ticketing BRT menawarkan penjualan tiket yang cepat dan efisien, dengan tiket tersebut akan diperiksa langsung di stasiun. 6. Intelligent Transportation System Penggunaan teknologi digital untuk meningkatkan kenyamanan, kecepatan dan keandalan, serta keamanan bagi penumpang, pengemudi, dan perencana.

2.6

GPS

33 Global Positioning System (GPS) adalah utilitas milik AS yang menyediakan pengguna dengan layanan pemberitahuan posisi, navigasi, dan waktu. Sistem ini terdiri dari tiga segmen: segmen luar angkasa, segmen kontrol, dan segmen pengguna. Tiga segmen tersebut dijelaskan sebagai berikut: 1. Segmen luar angka Segmen ini terdiri dari kumpulan satelit yang mentransmisi sinyal radio kepada para pengguna dengan menggunakan satelit luar angka yang diatur oleh Departemen Pertahanan Amerika Serikat. 2. Segmen kontrol Segmen ini terdiri dari jaringan global dari fasilitas untuk melacak satelit GPS, memonitor transmisi, melakukan analisis, serta mengirim perintah dan data kembali ke satelit. 3. Segmen pengguna Segmen pengguna terdiri dari peralatan penerima GPS, yang menerima sinyal dari satelit GPS dan menggunakan informasi yang ditransmisikan untuk menghitung posisi tiga dimensi dari si pengguna dan waktu. Dari ketiga segmen tersebut, angkatan udara AS mengembangkan, menjaga, dan mengoperasikan segmen luar angka dan segmen kontrol (National Coordination Office for Space-Based Positioning, Navigation, and Timing, 2014)

2.7

Web Service Web service adalah sistem perangkat lunak yang dirancang untuk guna

mendukung pertukaran informasi dan pemanfaatan informasi antara mesin ke mesin melalui jaringan. Hasil dari informasi tersebut ditampilkan dengan format yang dapat diproses kembali untuk digunakan (Booth, et al., 2004).

2.8

Artificial Intelligence Menurut Rusell dan Norvig (2010:1-2), Artificial Intellegence merupakan

semua kegiatan yang berhubungan dengan kerja tugas intelektual. Artificial Intellegence mempunyai empat kategori berbeda, yaitu:

34

Tabel 2.4 Empat kategori Artificial Intelligence Thinking Humanly

Thinking Rationally

Otomatisasi kegiatan yang dikaitkan

Studi tentang kemampuan mental

dengan pemikiran manusia, dengan

melalui penggunaan model komputasi

kegiatan seperti mengambil keputusan,

perhitungan yang memungkinkan

pemecahan masalah, dan

untuk merasakan, beralasan, dan

pembelajaran.

bertindak.

Acting Humanly

Acting Rationally

Seni menciptakan mesin yang

Kecerdasan komputasi adalah studi

menjalankan fungsi yang

tentang desain agen cerdas yang

membutuhkan kecerdasan ketika

berperilaku cerdas dalam artefak.

dilakukan oleh manusia.

Pada tabel 2.4, bagian atas tabel mengacu pada proses berpikir dan penalaran, sedangkan yang pada bagian bawah mengacu pada perilaku. Definisi bagian kiri tabel menyerupai otak manusia sedangkan pada bagian kanan merupakan ukuran kinerja yang ideal, atau disebut dengan rasionalitas.

2.9

Neural Network Menurut Haykin (2009:1-2), Artificial Neural Network (ANN), disebut juga

Neural Network (NN), berasal dari pemikiran bahwa cara kerja otak manusia sangat berbeda dengan cara kerja komputer digital tradisional. Kemampuan otak manusia menghitung selama ini diketahui sangat berbeda dengan komputer digital konvensional. Cara kerja otak diketahui sangatlah kompleks, nonlinear, sedangkan komputer bekerja secara paralel (sistem pemrosesan informasi). Otak memiliki kemampuan untuk mengatur konstituen struktural, yang dikenal sebagai neuron, sehingga untuk melakukan perhitungan tertentu (misalnya, pengenalan pola, persepsi, dan kontrol motor) berkali-kali lebih cepat dibandingkan komputer digital tercepat yang ada saat ini. Secara umum, NN adalah sebuah mesin yang dirancang untuk memodelkan cara kerja otak manusia dalam mengerjakan sebuah tugas atau fungsi dari sebuah tujuan.

35 Haykin (2009:1-2) menjelaskan bahwa NN merupakan pemroses yang terdistribusi secara paralel. NN terdiri dari unit pemroses sederhana yang memiliki kecenderungan untuk menyimpan pengetahuan yang berdasarkan pengalaman dan membuatnya tersedia untuk digunakan. NN menyerupai otak manusia dalam dua aspek, yaitu: 1. Pengetahuan yang diperoleh jaringan (network) dari lingkungannya melalui tahap pembelajaran. 2. Kekuatan koneksi interneuron, yang dikenal sebagai bobot sinaptik (synaptic weights), digunakan untuk menyimpan pengetahuan yang telah diperoleh.

Prosedur yang digunakan dalam proses pembelajaran disebut sebagai algoritma pembelajaran (learning algorithm). Algoritma pembelajaran tersebut merupakan fungsi untuk mengubah bobot sinaptik dari sebuah NN dengan teratur untuk mencapai tujuan yang diinginkan.

2.9.1 Karakteristik Neural Network Beberapa contoh sifat dan kemampuan yang penting dari NN sebagai berikut. 1.

Nonlinearity Sebuah neuron dapat bersifat linear maupun nonlinear. Jika sebuah NN terdiri dari interconnection yang berupa neuron nonlinear, maka NN tersebut dapat dikatakan sebagai NN yang bersifat nonlinear pula.

2.

Input-Output mapping Supervised learning melibatkan modifikasi terhadap bobot sinaptik dari sebuah NN dengan memberikan sejumlah contoh-contoh pelatihan. Setiap contoh tersebut terdiri dari sinyal input dan respons yang diinginkan. NN akan dipresentasikan dengan sebuah contoh yang diambil secara acak dari kumpulan contoh, dan bobot sinaptik akan dimodifikasi untuk meminimalkan perbedaan antara hasil yang diperoleh dengan hasil yang ingin dicapai. Proses modifikasi ini dilakukan secara berulang untuk beberapa contoh sampai NN mencapai suatu kondisi ketika tidak ada perubahan yang berarti terhadap bobot sinaptiknya.

3.

Fault Tolerance

36 Sebuah NN, yang diimplementasi dalam bentuk perangkat keras, akan memiliki potensi untuk menjadi fault tolerant secara inheren. Hal ini disebabkan oleh perhitungan yang kuat dari NN. Akibatnya, kinerja NN akan mengalami degradasi secara perlahan apabila kondisi operasi menjadi sangat buruk. Dengan kata lain, jika ada sebuah neuron dalam NN mengalami kerusakan, kinerja NN tersebut tidak akan terpengaruh secara signifikan.

2.9.2 Model Sebuah Neuron Seperti yang ditulis Haykin (2009:10-12), model dasar dari NN disebut juga sebagai models of a neuron. NN terdiri dari kumpulan proses unit, yang disebut sebagai neuron. Sebuah neuron terdiri dari tiga elemen dasar, yakni: 1.

Sekumpulan sinapsis (synapses) yang ditandai dengan bobot masingmasing.

2.

Sebuah adder (Σ/Summing junction) yang berfungsi untuk menjumlahkan semua sinyal input.

3.

Sebuah fungsi aktivasi (activation function) untuk membatasi amplitudo dari output sebuah neuron.

Gambar 2.20 Model Sebuah Neuron (Sumber: Haykin, 2009:11)

Arsitektur sebuah NN dapat dibagi menjadi tiga kelas, yaitu: 1.

Single-layer Feedforward Networks

37 Single-layer Feedforward Networks merupakan arsitektur yang paling sederhana. Arsitektur ini hanya terdiri dari satu lapisan input dan satu lapisan output. Dinamakan sebagai single-layer network karena merujuk pada lapisan output pada node komputasi. Lapisan input tidak dihitung sebagai node komputasi karena tidak ada komputasi yang terjadi pada lapisan input.

Input layer of

Output layer

source nodes

of neurons

Gambar 2.21 Feedforward Network (Sumber: Haykin, 2009:21)

38

2.

Multilayer Feedforward Networks Pada arsitektur ini terdapat satu atau lebih lapisan tambahan yang disebut sebagai hidden layers. Dengan menambahkan satu atau dua lapisan tersembunyi (hidden layers), NN dapat mengekstrak statistik dengan orde yang lebih tinggi dari input-nya.

Input layer

Layer of

Layer of

of source

hidden

output

nodes

neurons

neurons

Gambar 2.22 Multilayer Feedforward Network (Sumber: Haykin, 2009:22)

39

3.

Recurrent Networks Arsitektur ini merupakan feedforward neural network yang memiliki paling sedikitnya satu feedback loop.

Gambar 2.23 Recurrent Network (Sumber: Haykin, 2009:23)

2.10 Radial Basis Function Neural Nework Radial Basis Function Neural Network (RBFNN), merupakan feedforward network yang menggunakan RBF sebagai fungsi aktivasi. Pada umumnya, RBFNN terdiri dari 3 lapisan, yakni: 1. Lapisan input, terdiri dari

node awal, dengan

adalah dimensi dari

vektor masukan x. 2. Lapisan hidden, terdiri dari jumlah unit komputasi yang sama dengan jumlah contoh pelatihan (training sample).

40 3. Lapisan output, biasanya berupa satu unit komputasi. Jelasnya, tidak ada batasan jumlah unit komputasi pada lapisan ini. Akan tetapi, secara umum, ukuran lapisan output jauh lebih kecil dibandingkan dengan lapisan hidden.

Gambar 2.24 Stuktur Dasar Radial Basis Function Neural Network (Sumber: Haykin, 2009:240)

2.11 Android Menurut Google, Inc. (2014), Android adalah platform open source untuk mobile yang dipakai lebih dari seratus juta di lebih dari seratus sembilan puluh (190) negara di seluruh dunia. Setiap harinya lebih dari satu juta pengguna menyalakan perangkat Android baru mereka dan mulai mencari aplikasi, game, dan konten digital lainnya. Karena sifatnya open source, maka Android menjadi platform favorit bagi konsumen dan developer. Hal ini berdampak pada pertumbuhan yang kuat dalam konsumsi aplikasi. Pengguna Android mengunduh lebih dari satu miliar lima ratus juta aplikasi dan game dari Google Play setiap bulannya. Dengan mitra-mitranya, Android terus mendorong batas-batas perangkat keras dan perangkat lunak ke depan dengan membawa kemampuan baru untuk pengguna dan developer. Untuk developer, inovasi Android memungkinkan membangun aplikasi yang dibedakan dengan menggunakan teknologi mobile terbaru.

41

Gambar 2.25 Contoh Perangkat Android (Sumber: Google, Inc., 2014)

2.11.1 Arsitektur Android Menurut Burnette (2010:17-22), Android dapat dibagi menjadi lima lapisan, yaitu: 1.

Linux Kernel Android dibangun berdasarkan kernel Linux yang diciptakan oleh Linus Torvalds pada tahun 1991. Linux menyediakan lapisan abstraksi perangkat keras untuk Android. Android menggunakan Linux untuk manajemen memori, manajemen proses, jaringan, dan layanan sistem operasi lainnya

2.

Native Libraries Native libraries merupakan perpustakaan asli Android. Pustaka ini ditulis dalam bahasa pemrograman C atau C++, dikompilasi untuk arsitektur perangkat keras tertentu yang digunakan oleh smartphone, dan preinstalled oleh vendor ponsel. Beberapa native libraries yang tesedia, yaitu: a.

Surface Manager Android menggunakan Window Manager yang mirip pada sistem operasi Windows, tetapi jauh lebih sederhana.

b. 2D and 3D graphics

42 2D atau 3D dapat dikombinasikan pada satu tampilan antarmuka pengguna dengan Android. Pustaka akan menggunakan hardware 3D jika terdapat hardware yang mendukung. Jike tidak ada, maka akan menggunakan fast software render. c.

Media codecs Android dapat merekam atau memainkan video dan suara dengan format AAC, AVC (H.264), H.263, MP3, dan MPEG-4.

d. SQL database Android menggunakan database SQLLite untuk menyimpan data. e.

Browser engine Android menggunakan pustaka WebKit yang digunakan juga dalam browser Google Chrome, Safari, dan juga browser pada Iphone.

3.

Android Runtime Android runtime menggunakan library Java dan termasuk mesin virtual Dalvik. Dalvik VM (Virtual Machine) adalah implementasi Google Java yang dioptimalkan untuk perangkat mobile. Semua kode yang anda tulis untuk Android akan ditulis di Java dan dijalankan dalam mesin virtual.

4.

Application Framework Lapisan ini menyediakan alat tingkat tinggi yang akan dapat digunakan developer untuk membuat aplikasi. Kerangka kerja ini datang pre-installed dengan Android, tetapi developer juga dapat menambahkan komponen sendiri sesuai kebutuhan

5.

Application and Widgets Lapisan tertinggi dalam diagram arsitektur Android adalah lapisan Application and Widgets. Pengguna (end user) hanya akan melihat program pada lapisan ini, dan tak sadar terhadap semua tindakan yang terjadi dilapisan bawah. Aplikasi adalah program yang dapat mengambil alih seluruh layar dan berinteraksi dengan pengguna, sedangkan widget atau gadget, beroperasi hanya dalam bentuk persegi panjang kecil dari aplikasi layar.

43

Gambar 2.26 Contoh Arsitektur Android (Sumber: Burnette, 2010:18)

2.11.2 Siklus Hidup Android Menurut Burnette (2010:23), selama dalam proses, setiap activity dari program Android bisa di salah satu dari beberapa keadaan. Keadaan tersebut tidak dapat dikontrol secara langsung oleh developer, karena sudah diatur oleh sistem. Namun, developer mendapat pemberitahuan ketika sebuah keadaan akan berubah ketika sebuah fungsi dipanggil. Menurut Burnette (2010:23-25), terdapat sembilan fungsi yang digunakan pada kelas activity, yaitu: 1.

onCreate() Fungsi ini dipanggil ketika activity pertama kali dijalankan. Fungsi ini berguna untuk melakukan inisialisasi awal. Fungsi ini mempunyai satu parameter yang dapat diberisi null atau berupa informasi kondisi sebelumnya yang disimpan pada fungsi onSaveInstanceState().

2.

onStart() Fungsi ini menunjukan adanya activity yang akan ditampilkan kepada pengguna.

3.

onResume() Fungsi ini dipanggil ketika sebuah activity mulai berinteraksi dengan pengguna. Fungsi ini biasanya digunakan untuk menjalankan animasi dan musik.

44 4.

onPause() Fungsi ini dipanggil ketika activity tersebut akan masuk ke proses background, hal ini terjadi karena ada activity lainnya yang dipanggil.

5.

onStop() Fungsi ini dipanggil ketika sebuah tampilan activity tidak digunakan lagi oleh pengguna (tidak digunakan sementara waktu). Jika memori tidak mencukupi, fungsi ini mungkin tidak akan dipanggil, melainkan sistem akan menghancurkan proses activity tersebut.

6.

onRestart() Fungsi ini dipanggil pada saat sebuah activity kembali ditampilkan kepada pengguna dari keadaan berhenti.

7.

onDestroy() Fungsi ini dipanggil sesaat sebelum sebuah activity dihancurkan. Jika memori tidak mencukupi, fungsi ini mungkin tidak akan dipanggil, melainkan sistem akan menghancurkan proses activity tersebut.

8.

onSaveInstanceState(Bundle) Android akan memanggil fungsi ini untuk menyimpan keadaan sebelumnya, seperti letak kursor pada kolom teks sebelumnya. Fungsi ini tidak perlu diganti (override), karena implementasi standar telah mengontrolnya secara otomatis.

9.

onRestoreInstanceState(Bundle) Fungsi ini dipanggil ketika activity melakukan inisialisasi ulang dari kondisi

sebelumnya

yang

disimpan

dengan

fungsi

onSaveInstanceState(). Implementasi standar mengembalikan keadaan dari tampilan antarmuka sebelumnya.

45

Gambar 2.27 Contoh Siklus Hidup Android (Sumber: Google, Inc., 2014)

2.11.3 Building Blocks Menurut Burnette (2010:26), terdapat empat elemen penting untuk pengembangan aplikasi android, yaitu: 1.

Activities Activity adalah tampilan antarmuka. Aplikasi dapat menentukan satu atau lebih activity untuk menangani berbagai tahapan program. Setiap activity bertanggung jawab untuk menyimpan kondisi sendiri sehingga dapat dikembalikan sebagai bagian dari siklus hidup aplikasi. Activity merupakan turunan dari kelas context, sehingga developer dapat menggunakannya untuk mendapatkan informasi global tentang sebuah aplikasi

2.

Intents Intents adalah mekanisme untuk menggambarkan tindakan tertentu, seperti memilih foto. Di Android, hampir semuanya berjalan melalui intents.

3.

Services Services adalah proses yang berjalan di background, tanpa interaksi langsung dari pengguna. Sebagai contohnya adalah pemutar musik yang terus berjalan walaupun pengguna berpindah-pindah ke program yang berbeda.

4.

Content Providers Content Providers adalah sekumpulan data dibungkus dalam custom Application Program Interface (API) untuk membaca dan menulis. API

46 digunakan untuk berbagi data antar aplikasi. Sebagai contoh, Google menyediakan penyedia konten untuk informasi kontak yang dapat digunakan aplikasi lainnya.

2.12 The Ten Principles of Mobile Interface Design Menurut Stark (2012), terdapat sepuluh prinsip dari mobile interface design, yaitu: 1. Mobile mindset a.

Be focused: Fitur yang banyak bukanlah hal yang terbaik, melainkan berfokus pada fitur-fitur tertentu lalu dikembangkan sebaik mungkin.

b.

Be unique: Membuat aplikasi yang unik yang berbeda dengan aplikasi lainnya.

c.

Be charming: Aplikasi yang ramah, dapat diandalkan dan menyenangkan dapat membuat pengguna sangat nyaman untuk tetap terus menggunakannya.

d.

Be considerate: Developer terlalu sering berfokus dengan hal yang dikembangkan dan tujuan bisnis pribadi sehingga tidak berpikir dari sisi pengguna. Para developer harus menempatkan diri pada posisi pengguna untuk menciptakan aplikasi dengan pengalaman yang menarik.

2. Mobile context a.

Bored: Harus ada pengalaman yang mendalam dan menarik perhatian pengguna saat menggunakan aplikasi, sehingga pengguna tidak mudah bosan. Contoh: Facebook, Twitter dan Angry Birds.

b. Busy: Kemampuan untuk menyelesaikan tugas secara cepat dan andal dengan satu tangan pada lingkungan sibuk adalah hal yang penting. Contoh: email, calendar dan banking. c.

Lost: Pengguna mengeksplorasi sebuah tempat asing sehingga membutuhkan penggunaan baterai yang lama. Dalam hal ini, daya tahan baterai merupakan perhatian pertama sehingga diperlukan fitur offline untuk mengurangi penggunaan baterai. Contoh: Maps, Yelp dan Foursquare.

3. Global guidelines

47 a.

Responsiveness: Jika pengguna melakukan suatu tindakan, aplikasi harus merespons tindakan tersebut secara instan.

b. Polish: Menyempurnakan aplikasi hingga hal-hal yang paling detil. c.

Thumbs: Desain bedasarkan jempol, karena jari jempol hampir selalu digunakan dalam berinteraksi dalam layar touch screen.

d. Targets: Menentukan letak antar tombol sehingga pengguna tidak salah tekan. e.

Content:

Revolusi

layar

sentuh

adalah

bahwa

hal

tersebut

memungkinkan pengguna untuk berinteraksi langsung dengan konten tanpa menggunakan mouse dan keyboard. f.

Controls: Bila terdapat tombol kontrol, tempatkan tombol tersebut di bagian bawah layar. Jika tidak, pengguna tidak akan bisa melihat apa yang terjadi dengan konten pada saat menggunakan tombol kontrol.

g.

Scrolling: Bila memungkinkan, hindari scrolling. Memiliki layar nonscrolling membuat tampilan dirasa lebih solid dan dapat diandalkan daripada layar scrolling.

4. Navigation models a.

None: Aplikasi utilitas layar tunggal

b. Tab Bar: Tiga sampai enam bidang dengan isi yang berbeda c.

Drill Down: List dan konten detil hierarki

5. User Input a.

Keyboard variations: Pertimbangkan setiap input dan pastikan untuk menampilkan keyboard paling berguna untuk melakukan entri data.

b.

Keyboard options: Pertimbangkan setiap input dan memutuskan mana pilihan entri otomatis yang harus diaktifkan (auto-correct, autocapitalisation dan auto-complete).

c.

Keyboard orientations: Jika terdapat kebutuhan mengetik yang sering, harus dipastikan bahwa orientasi landscape agar tombol keyboard menjadi lebih besar dan mudah ditekan.

6. Gestures a.

Invisible: Gestures yang tidak terlihat, sehingga dibutuhkan waktu untuk menemukannya. Developer harus memutuskan bagaimana untuk mengungkapkan keberadaan Gestures kepada pengguna.

48 b. Two Hands: Penggunaan aplikasi menggunakan dua tangan untuk bekerja, seperti yang digunakan dalam aplikasi native Maps app pada iOS untuk melakukan zoom out/in. c.

Nice to Have: Dalam banyak hal, gestures merupakan hal baik untuk dimiliki, tapi tidak kritis. Seperti shortcut keyboard, beberapa pengguna menyenanginya, tetapi kebanyakan pengguna bahkan tidak akan tahu bahwa hal itu ada.

d. No Replacement: Sebuah kosa kata umum untuk gestures belum ada sehingga diperlukan sebuah kontrol terlihat bagi kebanyakan aplikasi. 7. Orientation a.

Portrait: Merupakan orientasi layar yang paling populer sehingga harus dioptimalkan terlebih dahulu.

b. Landscape: Jika terdapat kebutuhan mengetik yang sering, maka orientasi landscape harus diutamakan, sehingga pengguna dapat mengakses keyboard yang lebih besar. c.

Orientation Lock: Jika orientasi yang digunakan berubah-ubah, tambahkan sebuah orientasi kunci, sehingga pengguna dapat menggunakan orientasi yang sesuai dengan keinginan.

8. Communications a.

Provide feedback: Memberikan umpan balik untuk setiap interaksi. Jika tidak, pengguna akan bertanya-tanya apakah aplikasi mengalami freeze, atau tindakan yang dilakukan tidak tepat.

b. Modal alerts: Memunculkan dialog error pada saat terjadi kesalahan. Dialog error hanya digunakan ketika ada kesalahan yang serius. c.

Confirmation: Memunculkan dialog konfirmasi pada saat meminta pengguna untuk mengkonfirmasi.

9. Launching Aplikasi yang telah digunakan sebelumnya, harus beroperasi sesuai dengan kondisi terakhir sebelum pengguna tinggalkan. Hal ini akan memberikan rasa kecepatan dan sifat aplikasi yang responsif. Selain itu, sebaiknya memasang gambar sedikit mungkin pada saat loading pertama aplikasi. Banyaknya gambar membuat pengguna merasa tidak nyaman karena seolaholah seperti melihat iklan.

49

10. First Impressions a.

Your Icon: Ikon yang dibuat harus menarik perhatian dan

unik,

sehingga dapat bersaing dengan ikon-ikon lainnya. Ikon harus dibuat simpel, tetapi mempunyai kesan yang kuat sehingga memberikan kesan yang kuat terhadap aplikasi. b. First Launch: Pengguna mungkin bingung ketika mencoba untuk memperkenalkan diri dengan aplikasi baru. Pengguna akan segera menghapus aplikasi tersebut jika dianggap tidak user-friendly. Jika sebuah aplikasi menyediakan fungsionalitas yang kompleks, lebih baik dibuatkan tips dan trik untuk membantu pengguna.

2.13 Hypertext Markup Language Menurut Lloyd (2011:23-33), Hypertext Markup Language (HTML) adalah bahasa utama yang digunakan untuk membuat halaman web. Struktur dasar HTML meliputi: - Doctype - Tag - Tag - Tag