TA : Rancang Bangun Aplikasi Pelayanan Pada Restoran Berbasis Mobile Android.

(1)

RANCANG BANGUN APLIKASI PELAYANAN PADA

RESTORAN BERBASIS MOBILE ANDROID

TUGAS AKHIR

Program Studi S1 Sistem Informasi

Oleh:

PUSPAYATI RAMADHANIS 08410100421

FAKULTAS TEKNOLOGI DAN INFORMATIKA

(2)

Halaman

ABSTRAK ... v

KATA PENGANTAR ... vi

DAFTAR ISI ... viii

DAFTAR TABEL ... xii

DAFTAR GAMBAR ... xvi

DAFTAR LAMPIRAN ... xxii

BAB I PENDAHULUAN ... 1

1.1 Latar Belakang Masalah ... 1

1.2 Perumusan Masalah ... 3

1.3 Pembatasan Masalah ... 3

1.4 Tujuan ... 4

1.5 Sistematika Penulisan ... 4

BAB II LANDASAN TEORI ... 6

2.1 Java ... 6

2.2 Android ... 7

2.3 Aplikasi Mobile ... 9

2.4 Smartphone ... 10

2.5 Tablet PC ... 10

2.6 Android SDK (Software Development Kit) ... 11

2.7 Socket ... 11

(3)

2.10.1 Usecase Diagram ... 16

2.10.2 Activity Diagram... 16

2.10.3 Sequence Diagram ... 17

2.10.4 Class Diagram ... 17

2.10.5 Componen Diagram ... 17

2.10.6 Deployment Diagram ... 18

2.10.7 Statechart Diagram ... 18

2.11 System Development Life Cycle (SDLC) ... 18

2.12 Testing dan Implementasi Sistem ... 21

BAB III ANALISIS DAN PERANCANGAN SISTEM ... 23

3.1 Analisis Sistem ... 24

3.1.1 Identifikasi permasalahan ... 25

3.1.2 Analisis Permasalahan ... 25

3.1.3 Analisis Kebutuhan Sistem ... 27

3.2 Perancangan Sistem ... 32

3.2.1 Usecase Diagram ... 32

3.2.2 Activity Diagram... 44

3.2.3 Sequence Diagram ... 50

3.2.4 Class Diagram ... 55

3.2.5 ComponentDiagram ... 60

3.2.6 Deployment Diagram ... 61

(4)

3.4.1 Desain Interface Mobile Application ... 69

3.4.2 Desain Interface Desktop Application ... 73

3.5 Desain Test Case ... 82

BAB IV IMPLEMENTASI DAN EVALUASI ... 92

4.1 Implementasi Sistem ... 92

4.2 Kebutuhan Sistem ... 92

4.2.1 Kebutuhan Perangkat keras ... 93

4.2.2 Kebutuhan Perangkat Lunak ... 94

4.3 Pembuatan Aplikasi ... 96

4.3.1 Mobile Application ... 96

4.3.2 Desktop Application Client ... 96

4.3.3 Desktop Application Server ... 96

4.4 Implementasi Sistem ... 96

4.4.1 Implementasi Mobile Application ... 98

4.4.2 Implementasi Desktop Application ... 104

4.5 Uji Coba Fungsi Aplikasi ... 115

4.5.1 Uji Coba Fungsi Aplikasi pada Pelayan ... 116

4.5.2 Uji Coba Fungsi Aplikasi pada Checker... 123

4.5.3 Uji Coba Fungsi Aplikasi pada Bag. Dapur ... 128

4.5.4 Uji Coba Fungsi Aplikasi pada Kasir ... 130

4.5.5 Uji Coba Fungsi Aplikasi pada Manajer... 133

(5)

5.2 Saran ... 151

(6)

(7)

1.1 Latar Belakang Masalah

Restoran yang tersebar di beberapa tempat membuat restoran saling

bersaing untuk mendapatkan pelanggan. Untuk menjaga loyalitas pelanggan dan

memenangkan persaingan, banyak strategi yang ingin dikembangkan oleh

restoran. Salah satu strategi yang ingin ditingkatkan adalah mengenai pelayanan

customer.

Berdasarkan survey pada restoran Malioboro cabang Kartini Surabaya, terdapat 3 (tiga) permasalahan utama pada restoran mengenai proses pelayanan yang lamban. Yang pertama, pelayan mengalami kesulitan dalam melakukan pencarian meja kosong. Pada saat customer memasuki restoran, maka customer akan mencari meja kosong. Jika restoran sedang sepi pengunjung, maka customer bisa segera menemukan sendiri meja kosong. Bila restoran sedang ramai, customer

akan meminta bantuan pelayan untuk dicarikan meja kosong. Namun pelayan mengalami kesulitan dalam melakukan pencarian meja kosong tersebut karena terdapat 42 meja dengan kapasitas ±200 pada lantai 1 (satu) dan 10 meja dengan kapasitas ±35 orang pada lantai 2 (dua). Sehingga customer menunggu mendapatkan informasi meja kosong tersebut

(8)

bartender, lembar ketiga diletakkan pada meja customer. Rata-rata jumlah pengunjung dalam kondisi normal adalah ±100 orang dan dalam kondisi ramai ±200 orang. Dalam kondisi normal, customer mendapati proses pilih menu hingga menerima menu ± 30 menit. Pelayan akan semakin kerepotan pada saat restoran sedang ramai pengunjung, karena berkeliling dari meja customer ke meja komputer untuk merangkap pesanan, ke checker dan bartender. Hal tersebut menyebabkan proses pencatatan pemesanan menjadi lamban.

Permasalahan yang ketiga, sulitnya pelayan dalam mengingat dan mengatur booking/reservasi meja dikarenakan data reservasi yang tidak tersusun rapi. Sehingga pelayan kesulitan menentukan dan mencari pesanan meja yang perlu dipersiapkan 1 jam sebelum jam yang ditentukan

Berdasarkan permasalahan diatas, pihak restoran membutuhkan aplikasi

pelayanan restoran dengan memanfaatkan device Smart Phone Android dan

dukungan aplikasi dekstop dengan menggunakan metode pengembangan System

Development Life Cycle (SDLC) model Waterfall. Untuk proses pencarian kursi

kosong, aplikasi mobile menampilkan denah meja per ruangan. Denah meja

tersebut menampilkann meja dengan blok warna merah yang artinya terisi dan

tanpa blok yang artinya kosong. Kemudian pelayan memilih meja yang kosong

agar sistem melakukan penandaan blok warna merah pada denah. Proses

selanjutnya pelayanan menampilkan list menu untuk dilakukan proses

pencatatan pemesanan menu. Pelayan memilih menu-menu sesuai yang dipesan

customer. List pesanan disimpan, maka secara otomatis list pesanan tersebut

tampil pada aplikasi desktop checker untuk dilakukan pengontrolan pesanan

(9)

pesanan tampil pada layar komputer chef dan bartender. Status ”proses” menjadi

”selesai” bila pesanan sudah selesai dibuatkan dan list pesanan tidak muncul

kembali pada layar chef dan bartender kemudian dapat dilakukan proses

pembayaran oleh kasir. Penyimpanan data reservasi dilakukan oleh petugas kasir.

Sistem akan menampilkan meja yang di-booking dengan blok warna ungu pada

denah bila masuk pada 1 (satu) jam sebelum waktu ditentukan.

Dengan adanya aplikasi pelayanan pada restoran ini dapat membantu

pihak restoran dalam hal pelayanan mulai dari menangani proses pencarian meja

kosong, proses pencatatan pemesanan menu, hingga proses reservasi.

1.2 Perumusan Masalah

Berdasarkan uraian latar belakang masalah tersebut, maka perumusan masalahnya adalah bagaimana merancang dan membangun aplikasi pelayanan pada restoran yang terdiri dari:

1. Proses pencarian meja kosong.

2. Proses pemesanan menu.

3. Proses booking meja.

1.3 _{Pembatasan Masalah}

Adapun yang menjadi batasan-batasan masalah dalam perangkat lunak

ini, yaitu:

1. Untuk proses booking, aplikasi ini hanya menampilkan informasi mengenai

pemesan, jadwal booking dan lokasi meja yang dipesan. Serta untuk pemesan

(10)

2. Jeda waktu booking pada meja yang sama adalah 3 (tiga) jam.

3. Aplikasi ini diperuntukkan pada restoran secara umum dan data yang

dibutuhkan diambil dari restoran Malioboro cabang Kartini Surabaya.

4. Bahasa pemrograman yang digunakan adalah Bahasa Java.

5. Menggunakan database MySql.

1.4 Tujuan

Sesuai dengan permasalahan yang ada maka tujuan dari dibuatnya perangkat lunak ini adalah menghasilkan aplikasi pelayanan pada restoran yang terdiri dari:

1. Proses pencarian meja kosong.

2. Proses pemesanan menu.

3. Proses booking meja.

1.5 Sistematika Penulisan

Penulisan laporan Tugas Akhir ini secara sistematika diatur dan disusun

dalam 5 bab, yaitu:

BAB I PENDAHULUAN

Bab ini berisikan mengenai latar belakang masalah yang diangkat pada

topik Tugas Akhir, batasan masalah, tujuan yang ingin diacapai dari

Tugas Akhirdan sistematika penulisan laporan Tugas Akhir.

BAB II LANDASAN TEORI

Bab ini menjelaskan mengenai teori-teori yang mendukung dalam

(11)

Berbasis Mobile Android. Teori yang digunakan adalah mengenai Java,

Android, Aplikasi Mobile, Smartphone, Tablet PC, Android SDK

(Software Development Kit), Sistem Pelayanan Restoran, Sistem Basis

Data, UML, System Development Life Cycle (SDLC), Testing dan

Implementasi Sistem.

BAB III ANALISIS DAN PERANCANGAN SISTEM

Bab ini menjelaskan tentang tahap-tahap yang akan dilakukan dalam penyelesaian sistem terdiri dari analisis sistem (identifikasi permasalahan, analisis permasalahan, analisis kebutuhan sistem), perancangan sistem (diagram blok, arsitektur aplikasi, Use Case Diagram, Activity Diagram, Sequance Diagram, Class Diagram,

Componen Diagram, Deployment Diagram, Entity Relational

Diagram) Struktur Tabel dan Desain Interface.

BAB IV IMPLEMENTASI DAN EVALUASI

Bab ini menjelaskan tentang implementasi sistem, kebutuhan sistem, pembuatan aplikasi pelayanan pada restoran, implementasi sistem ,uji coba fungsi aplikasi pelayanan pada restoran untuk mencapai tujuan yang diharapkan dan evaluasi aplikasi pelayanan pada restoran.

BAB V PENUTUP

(12)

2.1 Java

Menurut Rickyanto (2003). Java adalah suatu teknologi di dunia

software komputer. Selain merupakan suatu bahasa pemrograman, Java juga

merupakan suatu platform. Java merupakan teknologi dimana teknologi tersebut mencakup java sebagai bahasa pemrograman yang memiliki sintaks dan aturan pemrograman sendiri. Juga mencakup java sebagai platform dimana teknologi ini memiliki virtual machine dan library yang diperlukan untuk menulis dan menjalankan program yang ditulis dengan bahasa pemrograman Java.

Java merupakan suatu teknologi yang unik dan revolusioner dan merupakan teknologi pertama di dunia software yang memiliki semboyan “write

once, run anywhere”. Semboyan tersebut telah terbukti karena banyak program

java dapat dijalankan diberbagai platform sistem operasi seperti Linux, Windows maupun Unix.

Adapun karakteristik Java menurut Rickyanto (2003) adalah:

a. Sederhana: Java tidak memiliki sintaks yang aneh tetapi banyak menggunakan

sintaks c++ yang sudah banyak dikenal, sehingga java tidak menyulitkan bagi para programmer. Bahkan java memberikan banyak keunggulan dan kemudahan dibanding C++

(13)

c. Dapat didistribusikan Dengan mudah: Sifat distribusi dari Java sangat tampak sebagai applet dan library yang mampu bekerja dalam jaringan dan bekerja dengan objek terdistribusi (RMI) dengan sangat baik.

d. Aman: Program Java memiliki library security serta policy yang membatasi akses applet di komputer client.

e. Diinterpretasi oleh interpreter: Java memerlukan virtual machine yang bertindak sebagai interpreter yang menterjemahkan bytecode (file class) menjadi bahasa mesin yang dimengerti oleh komputer host.

f. Portabel: Java dapat dijalankan diberbagai platform tanpa perubahan kode. g. Multi threading: Java memiliki banyak kemampuan untuk menangani dan

menjalankan banyak thread sekaligus.

h. Dinamis: Java merupakan teknologi yang terus berkembang dan hal ini tampak nyata sekali dengan library yang terus ditingkatkan kemampuan dan kelengkapannya.

i. Netral terhadap arsitektur hardware: Java dapat dijalankan dengan baik pada komputer yang memiliki arsitektur berbeda-beda.

j. Robust: Java merupakan teknologi yang mampu menolong programmer untuk menghasilkan program secara cepat dan handal karena Java mencegah adanya memori leaking, meniadakan pointer serta mencegah berbagai eror yang mungkin terjadi dengan adanya proses pengecekan awal pada kompilasi.

2.2 Android

Menurut Suprianto (2012), Android adalah sistem operasi bergerak

(14)

dimodifikasi. Android diambil alih oleh Google pada tahun 2005 dari Android, Inc.

Gambar 2.1 Arsitektur Sistem Operasi Android Secara garis besar sistem operasi Android terbagi menjadi lima tingkatan:

a. Linux kernel: Adalah kernel dasar Android. Tingkat ini berisi semua driver

perangkat tingkat rendah untuk komponen hardware perangkat Android

b. Libraries: Berisi semua kode program yang menyediakan layanan-layanan

utama sistem operasi Android.

c. Android Runtime: Kedudukannya setingkat dengan libraries. Android

Runtime menyediakan kumpulan pustaka inti yang dapat diaktifkan oleh pengembang untuk menulis kode aplikasi Android dengan bahasa pemrograman Java.

d. Application Framework: Adalah semacam kumpulan class built-in yang

(15)

e. Applications: Pada tingkat inilah kita akan bekerja. Seperti aplikasi Android pada umumnya yang dapat di-download dan di-instal dari market Android.

2.3 Aplikasi Mobile

Menurut Buyens (2001) aplikasi mobile berasal dari kata application

dan mobile. Application yang artinya penerapan, lamaran, penggunaan. Secara

istilah aplikasi adalah program siap pakai yang direka untuk melaksanakan suatu fungsi bagi pengguna atau aplikasi yang lain dan dapat digunakan oleh sasaran yang dituju, sedangkan mobile dapat diartikan sebagai perpindahan dari suatu tempat ke tempat yang lain.

Maka aplikasi mobile dapat diartikan sebuah program aplikasi yang dapat dijalankan atau digunakan walaupun pengguna berpindah-pindah dari satu tempat ke tempat yang lain serta mempunyai ukuran yang kecil. Aplikasi mobile

ini dapat diakses melalui perangkat nirkabel, pager, PDA, telepon seluler,

smartphone, dan perangkat sejenisnya. Perangkat mobile memiliki banyak jenis

dalam hal ukuran, desain dan layout, tetapi memiliki karakteristik yang sangat berbeda dari sistem desktop. Berikut karakteristik perangkat mobile, diantaranya: a. Ukuran yang kecil: Perangkat mobile memiliki ukuran yang kecil. Konsumen

menginginkan perangkat yang terkecil untuk kenyamanan dan mobilitas mereka.

b. Memory yang terbatas: Perangkat mobile juga memiliki memori yang kecil,

yaitu primary (RAM) dan secondary (disk).

(16)

d. Mengkonsumsi daya yang rendah: Perangkat mobile menghabiskan sedikit

daya dibandingkan dengan mesin desktop

e. Kuat dan dapat diandalkan: Karena perangkat mobile selalu dibawa kemana

saja, mereka harus cukup kuat untuk menghadapi benturan-benturan, gerakan,

dan sesekali tetesan-tetesan air.

f. Konektivitas yang terbatas: Perangkat mobile memiliki bandwith rendah,

beberapa dari mereka bahkan tidak tersambung.

2.4 Smartphone

Menurut Williams & Sawyer (2007), Smartphone adalah telepon selular dengan mikro prosesor, memori, layar dan modem bawaan. Smartphone

merupakan ponsel multimedia yang menggabungkan fungsionalitas PC dan

handset sehingga menghasilkan gadget yang mewah, dimana terdapat pesan teks,

kamera, pemutar musik, video, game, akses email, TV digital, search engine, pengelola informasi pribadi, fitur GPS, jasa telepon internet dan bahkan terdapat telepon yang juga berfungsi sebagai kartu kredit.

2.5 Tablet PC

(17)

2.6 Android SDK (Software Development Kit)

Menurut Suprianto (2012) SDK Android berisi debugger, library,

emulator, dokumentasi, contoh kode program dan tutorial. SDK Android adalah

mesin utama untuk mengembangkan aplikasi Android. Sedangkan menurut Safaat (2012) Android SDK adalah tools API (Application Programming Interface) yang diperlukan untuk mulai mengembangkan aplikasi pada platform Android menggunakan bahasa pemrograman Java. Sebagai platform aplikasi netral, Android memberi kesempatan untuk membuat aplikasi yang dibutuhkan yang bukan merupakan aplikasi bawaan handphone/ smartphone.

Cara kerjanya adalah Android SDK memberi library yang nantinya dapat digunakan oleh pembuat aplikasi untuk membuat applikasi Android. Aplikasi tersebut dapat di-debug dengan debugger yang sudah disediakan oleh SDK. Kemudian aplikasi tersebut dijalankan dengan menggunakan emulator yang juga sudah disediakan oleh Android SDK

2.7 Socket

(18)

Berbagai jenis socket berhubungan dengan berbagai rangkaian protokol yang mendasari dan berbagai susunan protokol dalam sebuah rangkaian. Salah

satunya adalah rangkaian protokol TCP/IP. Jenis utama dari socket dalam TCP/IP

adalah stream socket dan datagram socket. Stream socket menggunakan TCP sebagai protokol ujung ke ujung (dengan menggunakan IP sebagai dasarnya) dan memberikan jasa byte-stream yang reliable (terpercaya). Datagram socket menggunakan UDP (sekali lagi dengan IP sebagai dasarnya) dan memberikan datagram service paling mudah yang dapat digunakan oleh aplikasi untuk mengirim pesan individu sampa dengan panjang 65.500 byte. Sebuah TCP/IP socket diidentifikasi secara unik dengan Internet Address (alamat internet / IP), protokol ujung ke ujung (TCP/UDP) dan sebuah nomor port. Gambar 2.2

mengambarkan hubungan logika antara aplikasi, abstraksi socket protokol dan

nomor port dalam sebuah host

Gambar 2.2 Socket, Protocol dan Port

2.8 Sistem Pelayanan Restoran

(19)

Tujuan operasi restoran adalah untuk mencari untung. Selain bertujuan bisnis atau mencari untung, membuat puas para tamu pun merupakan tujuan operasi restoran yang utama. Urutan-urutan kerja di restoran waktu buka/ operasi adalah:

a. Menyambut dan mengucapkan salam: Memberi ucapan salam kepada tamu atau lebih lazim disebut greeting’s kepada tamu waktu masuk restoran.

b. Mendudukkan tamu: Tamu kita antarkan ke tempat duduk. Penerima tamu harus tahu pasti dimana atau meja-meja nomor berapa yang masih kosong atau belum dipesan tamu dan berapa kapasitas masing-masing.

c. Memberikan daftar minuman (waktu makan siang atau malam): Yang

dimaksud daftar minuman disini ialah minuman yang diminum tamu sebelum memulai makan dengan tujuan untuk membangkitkan nafsu makan.

d. Memberi daftar makanan: Penerima tamu juga dituntut untuk memahami

benar-benar makanan/produk yang dijual sehingga dapat menyarankan kepada tamu dengan baik dan penjualan dapat meningkat.

e. Menuangkan air es: Untuk memberikan kesempatan kepada tamu untuk

mempelajari daftar makanan atau menu yang telah diberikan, Waiter lalu menuangkan air es ke gelas tamu.

f. Mengambil pesanan tamu: Dalam restoran kecil, pesanan tamu diambil-dicatat dengan atau dalam memo, kemudian dipindahkan ke sebuah check/bill. Di dalam restoran yang lebih besar, pesanan diambil dan ditulis di atas sebuah

Kitchen Order Tiket (KOT), dibuat rangkap sejumlah system control restoran

(20)

g. Menuliskan pesanan tamu: Kadang-kadang ada restoran yang memakai sistem lain dalam menuliskan order/pesanan tamu. Ada juga yang pesanan tamu langsung disalin dari memo kedalam cek/ bill oleh captain. Cek sudah

carbonized, dibuat rangkap tiga atau empat.

h. Periksalah kebersihan dan kondisi piring: Yang cacat, retak atau gempil harus disingkirkan. Sedangkan yang kurang bersih/flek dikembalikan lagi tempat pencucian piring.

i. Periksa makanan pesanan tamu: Setiap pesanan tamu yang kita terima dari

dapur, sebelum masuk restoran perlu diperiksa terlebih dahulu.

j. Periksalah makanan penghias (Garnir): Setiap makanan yang dipesan tamu

pasti diberi makanan penghias, pelengkap dan penyerta/ garner.

k. Menghidangkan makanan pada tamu: Untuk menghidangkan makanan pada tamu lazimdipergunakan bagi persegi panjang.

l. Memberikan bill/cek: Bill atau cek dapat diberikan kepada tamu beberapa saat setelah tamu selesai makan makanan penutup serta meminum teh/kopinya. Atau kadang-kadang kita tunggu sesaat sampai tamu meminta billnya.

2.9 Sistem Basis Data

(21)

2.10 UML (Unified Modeling Language)

Menurut Fowler (2005). Unified Modeling Language (UML) adalah keluarga notasi grafis yang didukung oleh meta-model tunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun pemrograman berorientasi objek (OO)

Menurut Rosa (2011) pada perkembangan teknik pemrograman berorientasi objek, muncullah sebuah standarisasi bahasa pemodelan untuk membangun perangkat lunak yang dibangun dengan 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. UML merupakan bahasa visual untuk pemodelan dan komunikasi mengenai sebuah sistem dengan menggunakan diagram dan teks-teks pendukung.

Pada gambar UML terdiri dari 13 macam diagram dikelompokkan dalam 3 kategori. Pembagian kategori dan macam-macam diagram tersebut dapat dilihat pada gambar 2.3.

UML 2.3 Diagram

Structure Diagram _DiagramsBehavior Intraction Diagram Class Diagram

(22)

Berikut ini penjelasan singkat dari pembagian kategori tersebut.

a. Structur diagram yaitu kumpulan diagram yang digunakan untuk

menggambarkan suatu struktur statis dari sistem yang dimodelkan

b. Behavior Diagram yaitu kumpulan diagram yang digunakan untuk

menggambarkan kelakuan sistem atau rangkaian perubahan yang terjadi pada sistem

c. Interaction diagram yaitu kumpulan diagram yang digunakan untuk

menggambarkan interaksi sistem dengan sistem lain maupun interaksi antar subsistem pada suatu sistem

Dalam pembuatan Tugas Akhir ini, menggunakan beberapa jenis diagram yaitu: use Case Diagram, Activity Diagram, Sequance Diagram, Class

Diagram, ComponenDiagram, DeploymentDiagram dan Statechard Diagram

2.10.1 Usecase Diagram

Usecase diagram menyajikan interaksi antar usecase dan actor. Dimana

actor dapat berupa orang, peralatan atau sistem lain yang berinteraksi dengan

sistem yang sedang dibagun. Usecase menggambarkan fungsionalitas sistem atau persyaratan-persyaratan yang harus dipenuhi sistem dari pandangan pemakai. Sholiq (2006),

2.10.2 Activity Diagram

(23)

(business work flow). Dapat juga digunakan untuk menggambarkan aliran kejadian (flow of event) dalam use case. Sholiq (2006).

2.10.3.Sequance Diagram

Digunakan untuk menunjukkan aliran fungsionalitas dalam use case

yang disusun berdasarkan urutan waktu. Alur pembacaan diagram ini adalah dari atas ke bawah.Diagram ini dapat dibaca dengan memperhatikan objek-objek dan pesan-pesan yang ada pada diagram. Sholiq (2006).

2.10.4.Class Diagram

Menunjukkan interaksi anatar kelas dalam sistem. Kelas mengandung informasi dan tingkah laku (behavior) yang berkaitan dengan informasi tersebut. Sebuah kelas pada diagram kelas dibuat untuk setiap tipe obyek pada diagram sequensial atau diagram kolaborasi. Sholiq (2006).

2.10.5.Componen Diagram

(24)

2.10.6.Deployment Diagram

Menampilkan rancangan fisik jaringan dimana berbagai komponen akan terdapat disana. Diagram deployment digunakan oleh manajer proyek, arsitek sistem dan karyawan distribusi untuk memahami rancangan fisik sistem dan dimana saja terdapat subsistem yang akan dibuat. Diagram ini membantu manajer proyek mengkomunikasikan tentang apa yang sistem inginkan terhadap pemakai, juga membantu bagian pengembangan untuk merencanakan distribusi yang akan ditawarkan. Sholiq (2006).

2.10.7.Statechart Diagram

Diagram Statechart diagram atau Statechart diagram menyediakan sebuah cara untuk memodelkan bermacam-macam keadaan yang mungkin dialami oleh sebuah objek. Jika dalam diagram kelas menunjukkan gambaran statis kelas-kelas dan relasinya,diagram statechart digunakan untuk memodelkan tingkah laku dinamik sistem. Sholiq (2006).

2.11 Sytem Development Life Cycle (SDLC)

System Development Life Cycle (SDLC) adalah pendekatan bertahap

untuk melakukan analisa dan membangun rancangan sistem dengan menggunakan siklus yang spesifik terhadap kegiatan pengguna. Pengembangan sistem informasi dapat dilakukan dengan berbagai metode. Proses pengembangan sistem yang dimulai dari tahap perencanaan sampai implementasinya disebut dengan istilah

System Development Life Cycle (SDLC). Tahapan-tahapan SDLC menurut

(25)

a. Mengidentifikasi masalah, peluang dan tujuan.

Menentukan permasalahan-permasalahan apa yang terjadi dan apa yang menyebabkan sasaran pada sistem lama belum tercapai. Kemudian mengidentifikasi peluang pengembangan sistem termasuk fisibilitas secara teknis, ekonomis dan operasional bahwa peningkatan dapat dilakukan melalui penggunaan sistem informasi terkomputerisasi, selanjutnya pada tahap ini juga dilakukan identifikasi tujuan dari pengembangan sistem informasi.

b. Menentukan kebutuhan informasi

Memahami informasi apa yang dibutuhkan pemakai agar bisa ditampilkan dalam pekerjaan. Serta mengetahui detil fungsi-fungsi dalam sistem termasuk mengetahui siapa saja yang terlibat, kegiatan apa saja yang ada, lingkungan kerja yang mana, waktu yang diperlukan serta bagaimana mekanisme atau prosedur yang berlaku.

c. Menganalisis kebutuhan sistem.

Dilakukan penguraian suatu sistem informasi yang utuh ke dalam komponen-komponennya untuk mengidentifikasi dan mengevaluasi permasalahan-permasalahan, peluang-peluang, maupun hambatan-hambatan yang terjadi dan kebutuhan yang diharapkan sehingga dapat diusulkan perbaikan-perbaikannya.

d. Merancang sistem yang direkomendasikan.

(26)

1. Desain model dari sistem informasi yang akan dikembangkan.

2. Desain output adalah keluaran dari sistem informasi yang dapat dilihat, dapat berupa tampilan dilayar, kertas laporan dan sebagainya.

3. Desain input yang perlu didesain secara rinci dari input adalah bentuk dari dokumen dasar yang digunakan dan bentuk tampilan dari input di alat

input.

4. Desain basis data ini adalah mengintegrasikan kumpulan dari data yang saling berhubungan antara satu dengan lainnya dan membuatnya tersedia untuk aplikasi yang bermacam-macam di dalam suatu organisasi, yang terdiri dari beberapa file yang diperlukan dalam suatu proses pengolahan data.

5. Desain tehnologi digunakan untuk menerima input, menjalankan model, menyimpan dan mengakses data, menghasilkan dan mengirimkan keluaran dan membantu pengendalian sistem secara keseluruhan. Tehnologi ini perlu dirancang untuk menyesuaikan dengan sistem informasi yang akan digunakan dengan memperhatikan tiga hal pokok, yaitu perangkat keras, perangkat lunak dan teknisi.

e. Mengembangkan dan mendokumentasikan perangkat lunak.

Tahap ini dilakukan untuk mengembangkan suatu perangkat lunak yang diperlukan, dalam kegiatannya diperlukan kerjasama antara penganalisis dan pemrograman.

f. Menguji dan mempertahankan sistem.

(27)

g. Mengimplementasikan dan mengevaluasi sistem.

Implementasi sistem dilakukan setelah rancangan selesai dan melakukan evaluasi untuk revisi dengan segera terhadap sistem untuk memastikan kesesuaian dengan kebutuhan. Evaluasi diharapkan bahwa sistem baru lebih efisien operasionalnya dan efektif dalam pencapaian tujuan dan lebih mudah digunakan.

2.12 Testing dan Implementasi Sistem

Menurut Romeo (2003:3), Testing software adalah proses mengoperasikan software dalam suatu kondisi yang dikendalikan untuk:

a. Verifikasi. Apakah telah berlaku sebagaimana yang ditetapkan (menurut spesifikasi)?

b. Mendeteksi error.

c. Validasi. Apakah spesifikasi yang ditetapkan telah memenuhi keinginan atau kebutuhan pengguna yang sebenarnya?

Menurut Romeo (2003:33), Test Case merupakan tes yang dilakukan berdasarkan pada suatu inisialisasi, masukan, kondisi ataupun hasil yang telah ditentukan sebelumnya.

a. White Box Testing

White boxtesting atau glass boxtesting atau clear box testing adalah suatu

metode disain test case yang menggunakan struktur kendali dari disain prosedural. Metode disain test case ini dapat menjamin:

(28)

2. Semua logika keputusan dapat dites dengan jalur yang salah atau jalur yang benar.

3. Semua loop dapat dites terhadap batasannya dan ikatan operasionalnya. 4. Semua struktur internal data dapat dites untuk memastikan validasinya.

b. Black Box Testing

Black box testing atau behavioral testing atau specification-based

testing, input/output testing atau functional testing dilakukan tanpa sepengetahuan

detil struktur internal dari sistem atau komponen yang dites. Black box testing

berfokus pada kebutuhan fungsional pada software, berdasarkan spesifikasi kebutuhan dari software.

Menggunakan black box testing, perekayasa software dapat menggunakan sekumpulan kondisi masukan yang dapat secara penuh memeriksa keseluruhan kebutuhan funsional pada suatu program. Kategori error dapat diketahui melalui black box testing, antara lain:

1. Fungsi yang hilang atau tidak benar.

2. Error dari antar-muka.

3. Error dari struktur data atau akses eksternal database.

4. Error dari kinerja atau tingkah laku.

(29)

Pada tahap ini dilakukan analisis dan perancangan sistem. Menurut pressman (2001), model waterfall adalah model klasik yang besifat sistematis, berurutan dalam membangun software. Disebut dengan Waterfall karena tahap demi tahap yang harus dilalui harus menuggu selesainya tahap sebelumnya dan berjalan berurutan. Terdiri dari tahap analisis, desain, pengkodean dan pengujian.

Tahap analisis yaitu proses pengumpulan kebutuhan khususnya pada perangkat lunak. Pada tahap analisis menjelaskan tahap analisis sistem yang didalamnya terdiri dari identifikasi permasalahan, analisis permasalahan dan analisis kebutuhan sistem.

Tahap desain digunakan untuk mengubah kebutuhan-kebutuhan analisis menjadi representasi ke dalam bentuk “blueprint” perangkat lunak. Pada tahap ini,

terdiri dari desain model sistem, desain basis data, desain input output.

Pengkodean yaitu untuk dapat dimengerti oleh mesin (computer), maka desain harus diubah bentuknya menjadi bentuk yang dapat dimengerti oleh mesin yaitu ke dalam bahasa pemrograman melalui proses coding.

(30)

Output Output Analisis

Identiifkasi masalah

Analisis permasalahan

3 permasalahan restoran

Usulan aplikasi untuk restoran

Analisis kebutuhan sIstem Spesifikasi kebutuhan perangkat lunak

Desain

Desain model sistem

Desain basis data

Blok diagram aplikasi pelayanan restoran

Usecase Diagram Activity Diagram Sequence Diagram Class Diagram Component Diagram Deployment Diagram State Diagram

Desain input output

Physical Data Model (PDM)

Struktur Tabel

Desain Interface

Pengkodean

Aplikasi pelayanan pada restoran

Pengujian

Uji coba fungsi aplikasi Test Case

Evaluasi aplikasi Quesioner

Output

Gambar 3.1 Tahap Pengembangan Rancang Bangun Aplikasi Pelayanan pada Restoran

3.1 Analisis Sistem

(31)

3.1.1 Identifikasi Permasalahan

Proses pelayanan yang terjadi saat ini yaitu pelayan mencarikan kursi kosong dengan menengok langsung meja mana yang masih kosong, apabila meja yang berada di lantai 1 (satu) tidak tersedia, maka pelayan berjalan menengok meja yang ada di lantai 2 (dua) pada restoran. Sehingga pelayan mengalami kesulitan dalam pencarian kursi.

Permasalahan yang kedua, pelayan mencatat pesanan customer pada selembar kertas, kemudian pelayan memasukkan data pesanan tersebut pada aplikasi desktop yang tersedia dan mencetaknya sebanyak 3 (tiga) lembar. Lembar pertama diberikan kepada checker , lembar kedua diberikan kepada

bartender, lembar ketiga diletakkan pada meja customer. Rata-rata jumlah

pengunjung dalam kondisi normal adalah ±100 orang dan dalam kondisi ramai ±200 orang. Dalam kondisi normal, customer mendapati proses pilih menu hingga menerima menu ± 30 menit. Pelayan akan semakin kerepotan pada saat restoran sedang ramai pengunjung, karena berkeliling dari meja customer ke meja komputer untuk merangkap pesanan, ke checker dan bartender.

Sulitnya pelayan dalam mengingat dan mengatur booking/reservasi meja dikarenakan data reservasi yang tidak tersusun rapi. Sehingga pelayan kesulitan menentukan dan mencari pesanan meja yang perlu dipersiapkan 1 jam sebelum jam yang ditentukan.

3.1.2 Analisis Permasalahan

(32)

1. Pelayan masih harus menengok langsung atau menyisiri ruangan restoran

untuk dapat menemukan meja kosong yang sesuai baik yang ada di lantai 1 (satu) maupun lantai 2 (dua) pada resroran tersebut. Sehingga customer harus menunggu hingga pelayan menemukan meja kosong yang sesuai.

2. Pelayan masih menulis pesanan pada selembar kertas. Kemudian menginputkan menu pesanan pada aplikasi desktop untuk dirangkapkan 3 (tiga) lembar menu pesanan. Lembar pertama diberikan kepada checker , lembar kedua diberikan kepada bartender, lembar ketiga diletakkan pada meja

customer. Pelayan harus benar-benar mengingat menu mana yang pada hari

itu sedang kosong. Sehingga pelayan kesulitan dalam melakukan estimasi waktu pelayanan karena masih berkeliling kesana kemari.

3. Pelayan kesulitan menentukan dan mencari pesanan meja yang perlu dipersiapkan 1 jam sebelum jam yang ditentukan. Dengan cara mengingat kembali lembaran jadwal booking/pesanan yang tertempel pada meja kasir.

Setelah dilakukan identifikasi permasalahan, maka diperoleh gambaran mengenai hal-hal yang dapat membantu menyelesaikan permasalahan yang terjadi. Diantaranya adalah:

1. Membuat aplikasi yang dapat menampilkan denah meja kosong maupun terisi. Sehingga pelayan tidak perlu menyisiri ruangan baik yang ada di lantai 1 (satu) maupun lantai 2 (dua) pada restoran.

(33)

3. Membuat aplikasi yang dapat mencatat menu pesanan yang dapat terintegrasi

ke bagian checker, dan kasir.

4. Membuat aplikasi yang dapat menampilkan menu pesanan pada bartender dan

chef yang dikontrol oleh checker.

5. Membuat aplikasi yang dapat menangani proses pembayaran berdasarkan nomor meja.

6. Membuat aplikasi yang dapat menangani proses penjadwalan

booking/pemesanan meja. Sehingga pelayan segera mengetahui meja yang

sedang di-booking.

7. Membuat aplikasi yang dapat memberikan informasi berupa laporan penjualan, laporan menu favorit, dan laporan utility meja berdasarkan harian maupun bulanan.

3.1.3 Analisis Kebutuhan Sistem

Berdasarkan permasalahan diatas maka dibutuhkan sistem aplikasi yang diantaranya dapat melakukan:

1. Proses Login:

a. Mengisi id dan password login berdasar hak akses user 2. Mengolah data master:

a. Menyimpan, ubah, hapus data master user b. Menyimpan, ubah, hapus data master menu c. Menyimpan, ubah, hapus data master ruangan d. Mengatur denah meja per-ruangan

(34)

a. Mengisi jumlah stok per item menu b. Mengisi jumlah stok secara keseluruhan 4. Proses pemilihan meja:

a. Menampilkan denah meja berdasarkan ruangan b. Menampilkan tanda meja yang isi dan kosong

c. Menandai meja sementara saat customer sedang pilih menu d. Menggabungkan meja dan pindah meja

5. Proses mencatat menu pesanan :

a. Menampilkan menu berdasarkan jenis menu b. Menampilkan informasi menu yang stoknya habis c. Menampilkan harga pemesanan menu

d. Merubah pesanan (menambah dan mengurangi jumlah menu) e. Mencatat pemesanan menu spesial

f. Mengirimkan list pesanan ke checker

g. Menampilkan status pesanan 6. Proses checking pesanan

a. Menampilkan list pesanan b. Merubah status pesanan c. Menampilkan riwayat pesanan 7. Proses pembayaran:

a. Menampilkan biaya yang harus dibayarkan berdasarkan nomor meja b. Memotong total pembayaran dengan menggunakan voucer

(35)

8. Proses reservasi:

a. Menyimpan data reservasi b. Menghapus data reservasi c. Mengubah data reservasi d. Memilih meja

e. Menandai meja reservasi 9. Proses membuat laporan

a. Memilih jenis laporan b. Menampilkan laporan harian c. Menampilkan laporan bulanan

Gambar 3.2 Arsitektur Aplikasi Pelayanan pada Restoran Berbasis Android

(36)

dan desktop application menggunakan komputer yang dioperasikan checker, kasir, petugas dapur (bartender dan chef) dan manajer. Tablet dan komputer tersebut terhubung dengan server lokal yang berisikan database dengan menggunakan jaringan Wifi. Semua data yang masuk disimpan didalam database

milik server lokal.

User pelayan bertugas mencarikan meja apabila customer kesulitan mencari meja sesuai dengan yang dibutuhkan, mencatat menu pesanan customer, serta menyiapkan meja yang sudah dibooking/dipesan pada 1 (satu) jam sebelum jadwal agar meja tersebut tidak dapat digunakan oleh customer lain. Mobile

application yang diakses oleh pelayan dapat menampilkan denah meja (tampak

meja isi/kosong/terpesan sesuai dengan jenis ruangan, menampilan menu tersedia, mencatat menu pesanan yang kemudian sistem akan otomatis mengirimkan menu pesanan ke Checker dan dapat melihat jadwal booking/pemesanan meja. Sistem akan otomatis menampilkan meja yang dipesan/ booking pada 1 (satu) jam sebelum jadwal dengan tanda meja berwarna ”ungu” dan data pemesan (nama

pemesan dan jam pemesanan)

User Checker bertugas dalam mengisi data master (menu, user,

ruangan), mengisi data stok menu harian yang tersedia setiap harinya, mengontrol antrian menu pesanan (menampilkan beberapa pesanan ke layar bagian Dapur dan melakukan pengecekan menu pesanan yang sudah dibuatkan oleh petugas dapur).

Desktop aplication pada checker berfungsi sebagai maintenance data master,

pengisian stok menu harian guna menentukan jumlah stok menu yang akan disediakan, pengontrolan pesanan (merubah status pesanan ”menunggu” menjadi

(37)

status pesanan ”selesai” agar pesanan yang selesai dibuat tidak tampil pada layar

bagian dapur). Checker dapat mengecek riwayat dari menu pesanan yang sudah selesai dibuat.

User bagian dapur bertugas hanya dalam membuatkan menu pesanan. Bagian dapur cukup hanya melihat menu pesanan pada layar bagian dapur (chef

dan atau bartender). Desktop application yang ada dibagian dapur hanya digunakan untuk melihat menu pesanan yang akan dibuatkan. Menu-menu yang muncul pada layar dapur dikontrol oleh checker. Menu pesanan yang muncul pada layar dapur hanya beberapa item pesanan. Sebelum jam operasional dimulai, petugas dapur (chef dan bartender) dapat memilih jenis tampilan sesuai kebutuhan pada ”form tampilan dapur” diantaranya adalah: makanan dan minuman

digabung, makanan dan minuman dipisah, makanan saja dan minuman saja

User kasir bertugas dalam melakukan proses pembayaran dan

menangani proses reservasi/booking/pemesanan meja. Pemesanan dapat dilakukan via telepon yang dilayani oleh petugas kasir maupun langsung di tempat. Aplikasi dekstop pada kasir berfungsi sebagai transaksi pembayaran dan transaksi reservasi dengan cara mencatat data pemesanan (nama pemesan, jadwal, lokasi meja dan no telepon yang bisa dihubungi). Jadwal reservasi otomatis akan muncul meja terblok warna ”ungu’ pada denah meja di mobile application pada 1

(satu) jam sebelum jadwal pemesanan.

Serta user manajer bertugas dalam melihat laporan-laporan baik laporan harian maupun bulanan yang diperoleh dari data yang tersimpan pada database.

Manajer dapat memilih jenis laporan: penjualan, utility meja dan menu favorit.

(38)

yang diinginkan seperti laporan penjualan, laporan utility meja dan menu favorit baik harian maupun bulanan.

3.2 Perancangan Sistem

Perancangan sistem adalah tahap untuk memberikan gambaran yang jelas dari rancangan aplikasi yang akan dibuat, sehingga memudahkan pemahaman mengenai sistem yang dibangun. Tahap perancangan sistem ini meliputi: UML (meliputi use Case Diagram, Activity Diagram, Sequance

Diagram, ClassDiagram, Statechart Diagram, Componen Diagram, Deployment

Diagram, Statechart diagram) , Physical Data Model (PDM), struktur tabel,

Rancangan Desain Input dan Output dan rancangan quesioner

3.2.1 Use Case Diagram

Use case diagram menyajikan interaksi antar use case dan actor. Use case digunakan untuk mengetahui yang terdapat didalam sistem informasi dan siapa saja yang berhak menggunakan fungsi-fungsi tersebut. Dalam tahap ini, penggambaran use case tampak pada gambar 3.3.

Setelah melakukan analisa terhadap sistem, diketahui bahwa restoran memiliki pegawai pelayan, checker, bagian dapur, kasir dan manager, serta melayani pelanggan dalam proses bisnisnya. Untuk mencari actor, dilakukan identifikasi yang ada di dalam ruang lingkup (Business Worker) dan berada di ruang lingkup (Business Actor). Setelah melakukan identifikasi, ditemukan satu

Business Actor yaitu pelanggan dan ditemukan 5 Business Worker yaitu pelayan,

(39)

Pelayan bertugas mencarikan meja kosong untuk pelanggan, kemudian mencatat menu pesanan, selanjutnya mengirimkan list pesanan tersebut ke

checker dan bartender. Pelayan dapat menunjukkan list pesanan yang sudah di

pesan customer. Pelayan mencatat nomor meja jika pelanggan melakukan pindah meja atau menggabung meja. Checker bertugas mengontrol stok dan mengontrol pesanan (menentukan menu yang dibuat oleh bagian dapur). Bagian dapur menerima list menu pesanan yang harus dibuat untuk diproses. Kasir bertugas menerima pembayaran dan mencatat reservasi. Sedangkan manajer bertugas membuat laporan. Dari uraian diatas, dapat diidentifikasi beberapa usecase, yaitu login, mengolah data master, memilih meja, mencatat menu pesanan, checking

pesanan, pembayaran, reservasi meja, membuat laporan. Setelah ditemukan actor

dan usecase, maka dapat digambar usecasediagram seperti pada gambar 3.3.

(40)

Berikut adalah penjelasan singkat dari masing-masing use case diagram

aplikasi pelayanan pada restoran:

Tabel 3.1 Tabel Flow of Event Usecase Login

Use case Name Login

Brief Description Use case ini mengatur proses login user

Primary Actor Pelayan

Manajer Checker Bag. Dapur Kasir

Secondary Actor -

Pre-Condition -

Post-Condition User masuk ke dalam sistem

Included Use case -

Basic Flow of

Events

Actor’s Action Sistem’s Response 1 .User password apakah sudah benar dengan cara mengambil data sesuai username yang dimasukkan user dari database dan membandingkan apakah password yang dimasukkan user setelah dienkripsi dengan MD5 sama dengan password yang tersimpan pada database

3. Jika username dan password benar, sistem menampilkan tampilan utama

Alternate Flow of Events

3a. Jika username dan password salah, maka sistem akan menampilkan tampilan login dengan informasi login gagal

Extension Points -

Tabel 3.2 Tabel Flow of Event Usecase Mengolah Data Master

Use case Name Mengolah data master

Brief Description Use case ini mengatur proses memasukkan, mengubah dan

menghapus data master

Primary Actor Checker

Secondary Actor -

Pre-Condition Checker sudah login ke dalam sistem

(41)

Basic Flow of

Events

Actor’s Action Sistem’s Response 1 . Checker memilih

menu data master 3 .Checker

memasukkan, mengubah atau menghapus data master

2 . Sistem menampilkan form data master

4. Sistem menyimpan/menghapus data master pada database

5. Jika sistem berhasil menyimpan/menghapus data master, data akan muncul/hilang pada tabel

5a. Jika sistem gagal menyimpan/menghapus data master, maka sistem akan menampilkan pesan kesalahan

Tabel 3.3 Tabel Flow of Event Usecase Memasukkan Stok Menu Harian

Use case Name Memasukkan stok menu harian

Brief Description Use case ini untuk memasukkan stok menu setiap hari

Secondary Actor Pelayan

Pre-Condition -Checker sudah login ke dalam sistem

-Stok hari ini belum dimasukkan

Post-Condition Data stok tersimpan dalam sistem

Basic Flow of

Events

Actor’s Action Sistem’s Response 1. Checker memilih

menu stok

(42)

Tabel 3.4 Tabel Flow of Event Usecase memilih meja

Use case Name Memilih meja

Brief Description Use case ini digunakan untuk memilih meja yang akan

digunakan oleh customer

Secondary Actor -

Pre-Condition -Pelayan sudah login ke dalam sistem

-Data master ruangan dan meja sudah diisi oleh checker

Post-Condition Meja terpilih dan diberi penanda warna merah

Basic Flow of

Events

Actor’s Action Sistem’s Response 1. Pelayan

menyentuh gambar meja dan mengklik tombol pilih meja

2. Sistem menyimpan data meja sesuai dengan meja yang dipilih. Meja ditandai dengan status terpakai. 3. Sistem menampilkan halaman pemesanan menu

-

Extension Points -Pindah meja

-Gabung meja

Tabel 3.5 Tabel Flow of Event Usecase Mencatat Menu Pesanan

Use case Name Mencatat menu pesanan

Brief Description Use case ini digunakan untuk melakukan proses pemesanan

menu

Secondary Actor -

Pre-Condition -Pelayan sudah login ke dalam system

-Data master menu sudah diisi oleh checker -Data stok harian sudah diisi oleh checker -Pelayan sudah memilih meja

Post-Condition Menu pesanan customer tersimpan dalamdi dalam system

Basic Flow of

Events

Actor’s Action Sistem’s Response

1. Pelayan mengklik menu yang ingin dipesan dan mengklik tombol simpan

(43)

besar/sama dengan jumlah yang dipesan

3. Sistem menyimpan data pesanan pada database

4. Jika pesanan tersimpan, sistem akan menampilkan halaman utama

2a. Jika menu pesanan kehabisan stok, maka sistem akan menampilkan pesan kesalahan

3a. Jika sistem gagal menyimpan pesanan, maka sistem akan menampilkan pesan kesalahan

Extension Points -Memesan menu special

-Merubah pesanan

-Menampilkan status pesanan

Tabel 3.6 Tabel Flow of Event Usecase Memesan Menu Spesial

Use case Name Memesan menu spesial

Brief Description Use case ini digunakan untuk memberi catatan pada pesanan

customer jika customer menginginkan menu dengan

penanganan khusus

Secondary Actor -

Pre-Condition Pelayan telah mengklik menu yang diinginkan

Post-Condition Catatan menu khusus tesimpan dalam system

Basic Flow of

Events

Actor’s Action Sistem’s Response 1. Pelayan mengklik tombol

jumlah pesanan pada menu yang ingin ditambahkan catatan

3. Pelayan memasukkan catatan menu special dan mengklik tombol ubah

2. Sistem menampilkan dialog pesanan special

Tabel 3.7 Tabel Flow of Event Usecase Menampilkan Status Pesanan

Use case Name Menampilkan status pesanan

Brief Description Use case ini digunakan untuk menampilkan pesanan

(44)

Secondary Actor Checker

Pre-Condition Pelayan telah melakukan pemesanan menu

Post-Condition Tampil halaman list pesanan

Basic Flow of

Events

1. Pelayan memilih meja yang telah dipakai dan mengklik tombol lihat meja

2. Sistem mengambil data pesanan pada database berdasarkan id meja yang dipilih 3. Sistem menampilkan list pesanan customer

2a. Jika sistem gagal mengambil data pesanan, maka sistem akan menampilkan pesan kesalahan

Tabel 3.8 Tabel Flow of Event Usecase Gabung Meja

Use case Name Gabung meja

Brief Description Use case ini digunakan untuk melakukan penggabungan

meja

Secondary Actor -

Pre-Condition -Pelayan telah melakukan pemesanan menu

-Pelayan telah masuk ke halaman list pesanan

Post-Condition Meja yang digabung akan disimpan di sistem dan diberi

tanda merah

Basic Flow of

Events

1. Pelayan mengklik tombol gabung meja 3. Pelayan memilih meja yang akan digabung dan digabung pada database. Meja ditandai dengan status terpakai.

5. Jika sistem berhasil menyimpan data meja digabung, meja yang digabung (berstatus terpakai) akan bertanda merah.

6. Sistem menampilkan halaman list pesanan

(45)

Events sistem akan menampilkan pesan kesalahan

Tabel 3.9 Tabel Flow of Event Usecase Pindah Meja

Use case Name Pindah meja

Brief Description Use case ini digunakan untuk melakukan pindah meja

Secondary Actor -

Post-Condition Meja berpindah dari meja awal ke meja yang dipilih

(penanda merah pada meja awal hilang dan muncul pada meja yang dipilih)

Basic Flow of

Events

Actor’s Action Sistem’s Response 1. Pelayan mengklik

tombol gabung meja

3. Pelayan memilih meja yang akan ditempati dan mengklik tombol pilih

2. Sistem akan menampilkan halaman peta meja

4. Sistem menyimpan data meja yang dipindah dan mengubah data meja lama. Meja lama diupdate dengan status selesai dan meja baru ditandai dengan status dipakai 5. Jika sistem berhasil menyimpan data meja dipindah, meja yang dipindah (berstatus dipakai) akan ditandai merah dan meja lama (berstatus selesai) tidak ditandai merah.

6. Sistem menampilkan halaman list pesanan

4a. Jika sistem gagal menyimpan data meja dipindah, maka sistem akan menampilkan pesan kesalahan

Tabel 3.10 Tabel Flow of Event Usecase Mengubah Pesanan

Use case Name Mengubah pesanan

Brief Description Use case ini dilakukan untuk mengubah pesanan

(46)

Secondary Actor -

Post-Condition Pesanan yang disimpan sistem berubah sesuai perubahan

yang dilakukan

Basic Flow of

Events

Actor’s Action Sistem’s Response 1. Pelayan menambah

atau mengurangi

pesanan 2. Sistem meverifikasi menu pesanan dengan mengecek apakah jumlah yang ditambah lebih kecil/sama dengan sisa stok menu jika pelayan melakukan penambahan. Jika melakukan pengurangan, maka tidak dilakukan verifikasi

3. Sistem menyimpan data pesanan yang sudah diupdate pada database 4. Jika pesanan tersimpan, sistem akan menampilkan halaman list pesanan

2a. Jika menu pesanan kehabisan stok, maka sistem akan menampilkan pesan kesalahan

3a. Jika sistem gagal menyimpan pesanan, maka sistem akan menampilkan pesan kesalahan

Tabel 3.11 Tabel Flow of Event UsecaseChecking Pesanan

Use case Name Checking pesanan

Brief Description Use case ini digunakan untuk mengontrol pesanan

Secondary Actor Bag. Dapur

Pre-Condition Pelayan sudah melakukan pemesanan menu

Post-Condition Status pesanan sesuai dengan yang ditentukan checker

Included Use case Mengubah status pesanan

Basic Flow of

Events

Actor’s Action Sistem’s Response 1. Checker mengatur

tampilan tabel pesanan dengan mengklik judul

tabel 2. Sistem mengambil data

pesanan hari ini dari database dan menampilkan data sesuai dengan pengaturan checker

(47)

Events

Tabel 3.12 Tabel Flow of Event Usecase Mengubah Status Pesanan

Use case Name Mengubah status pesanan

Brief Description Use case ini digunakan untuk mengubah status pesanan

sesuai dengan kondisi actual

Secondary Actor Dapur

Pre-Condition -

Post-Condition Status pesanan berubah sesuai dengan status saat ini

Basic Flow of

Events

Actor’s Action Sistem’s Response 1. Checker memilih

pesanan yang ingin diubah statusnya dan mengklik tombol ubah status

2. Sistem mengubah status pesanan. Jika status saat ini adalah menunggu, maka akan diubah menjadi proses. Jika status saat ini adalah proses maka diub

3. Jika status berhasil diubah, sistem akan menampilkan data pada tabel

2a. Jika sistem gagal mengubah status pesanan, sistem akan menampilkan pesan kesalahan

Tabel 3.13 Tabel Flow of Event Usecase Pembayaran

Use case Name Pembayaran

Brief Description Use case ini digunakan dalam proses pembayaran

Primary Actor Kasir

Secondary Actor -

Pre-Condition Status seluruh pesanan customer telah diubah menjadi selesai

Post-Condition -Pembayaran disimpan dan meja diset menjadi tidak terpakai

Included Use case -Mencetak struk

Basic Flow of

Events

Actor’s Action Sistem’s Response 1. Kasir memasukkan

nomor meja dan

mengklik tombol cari 2. Sistem akan mencari dan mengambil data pesanan berdasarkan nomor meja yang diinputkan

(48)

4. Kasir memasukkan jumlah pembayaran dan mengklik tombol bayar

menghitung total harga

5. Sistem menyimpan data pembayaran pada database dan mengubah status data meja dari dipakai menjadi selesai

6. Sistem menampilkan struk pembayaran

2a. Jika nomor meja yang dicari tidak memiliki pesanan, maka sistem akan menampilkan pesan kesalahan

4a. Jika kasir memasukkan jumlah pembayaran yang salah, maka sistem akan menampilkan pesan kesalahan

5a. Jika sistem gagal menyimpan data pembayaran, maka sistem akan menampilkan pesan kesalahan

Tabel 3.14 Tabel Flow of Event Usecase Mencetak Struk

Use case Name Mencetak struk

Brief Description Use case ini digunakan untuk melakukan cetak struk

Secondary Actor -

Pre-Condition Kasir telah melakukan proses pembayaran

Post-Condition Struk tercetak

Basic Flow of

Events

Actor’s Action Sistem’s Response 1. Kasir mengklik tombol cetak

saat sistem menampilkan struk pada use case memproses

pembayaran 2. Sistem mencetak struk

-

Tabel 3.15 Tabel Flow of Event Usecase Memproses Reservasi Meja

Use case Name Memproses reservasi meja

Brief Description Use case ini digunakan untuk melakukan proses reservasi

Pre-Condition -

Post-Condition Data reservasi tersimpan dalam sistem

Included Use case Menandai meja pesanan

(49)

Events 1. Kasir memasukkan

data reservasi 2. Sistem meverifikasi data reservasi dengan mengecek apakah meja yang akan tersedia, maka sistem menyimpan data reservasi pada database

4. Sistem menampilkan data reservasi pada tabel

2a. Jika waktu dan atau meja yang dipilih sudah dipesan sebelumnya, maka sisem akan menampilkan pesan kesalahan 3a. Jika sistem gagal menyimpan reservasi, maka sisem akan menampilkan pesan kesalahan

Tabel 3.16 Tabel Flow of Event Usecase Menandai Meja

Use case Name Menandai meja pesanan

Brief Description Use case ini digunakan untuk menandai meja yang telah

digunakan

Pre-Condition Data reservasi telah tersimpan pada system

Post-Condition Data meja yang dipesan disimpan pada system

Basic Flow of

Events

Actor’s Action Sistem’s Response 1. Kasir melakukan

reservasi sesuai use case memproses

reservasi meja 2. Sistem akan memberikan tanda warna ungu pada meja yang statusnya dibooking dan waktu saat ini berada pada rentang 1 jam sebelum jam booking sampai jam booking.

-

Tabel 3.17 Tabel Flow of Event Usecase Membuat Laporan

Use case Name Membuat laporan

(50)

Primary Actor Manager

Secondary Actor -

Pre-Condition Manager telah login ke dalam system

Post-Condition Tampil laporan

Included Use case Memilih jenis laporan

Basic Flow of

Events

1. Manajer memilih menu laporan yang diinginkan 3. Manajer memasukkan data filter yang diinginkan dan mengklik tombol lihat laporan

2. Sistem menampilkan filter laporan

4. Sistem mengambil data dari database sesuai filter dan menampilkan dalam bentuk laporan

-

Tabel 3.18 Tabel Flow of Event Usecase Memilih Jenis Laporan

Use case Name Memilih jenis laporan

Brief Description Use case ini digunakan untuk memilih jenis laporan yang

akan dilihat

Primary Actor Manajer

Secondary Actor -

Pre-Condition -Manajer telah memilih menu laporan yang diinginkan

Sistem telah menampilkan filter laporan

Post-Condition Jenis laporan terpilih

Included Use case

Basic Flow of

Events

1. Manajer memilih jenis laporan

3.2.2 Activity Diagram

Activity Diagram atau Diagram aktivitas menggambarkan aliran kerja/

(51)

Berikut beberapa penjelasan singkat mengenai activity diagram proses yang berkaitan dengan pelayanan restoran:

a. Activity Diagram Proses Login Mobile Application

Proses Login diawali oleh user pelayan memasukkan data username

dan password. Data inputan dikirim oleh mobile application ke server dengan

menggunakan jaringan internet lokal. Server mengecek data inputan tersebut apakah ada atau tidak pada database user. Jika data login tidak sesuai maka

mobile application menampilkan pesan bahwa login gagal dan meminta untuk

memasukkan username dan password yang benar. Jika data login yang dimasukkan sudah benar maka mobile application menampilkan denah meja Untuk lebih jelasnya dapat dilihat pada gambar 3.4.

User Client Server

Input username dan password _{Mengirim data ke server} _{Mengecek data login}

Muncul pesan login salah

Tampil form denah

Salah

Benar

Gambar 3.4 ActivityDiagram Proses Login

b. Activity Diagram Proses Pilih Meja

Mobile application menampilkan denah meja, pelayan memilih meja

yang artinya mobile application menandai meja sementara untuk disimpan pada

server. Mobile application meminta list menu pada server, server memberikan

data menu yang tersedia sehingga tampil list menu pada mobile application.

(52)

pelayan memilih batal pilih menu kemudian memilih simpan meja, maka sistem akan melakukan lock (penguncian tanda merah pada meja), jika tidak disimpan maka akan keluar dari sistem yang artinya tanda sementara akan hilang.

Pelayan Mobile Server

Tampil form denah meja Pilih meja

Penandaan meja sementara Simpan tanda sementara

Minta list menu Ambil data menu

Tampil list menu

Pesan menu

Lock Meja Batal pilih menu

Simpan meja

Tidak Pilih menu

Gambar 3.5 Activity Diagram Proses Pilih Meja

c. Activity Diagram Proses Pemesanan Menu

Mobile application menampilkan list menu yang tersedia, kemudian

(53)

Gambar 3.6 Activity Diagram Proses Pemesanan

d. Activity Diagram Proses Pembayaran

Proses pembayaran dilakukan oleh kasir dengan menggunakan aplikasi desktop. Aplikasi desktop menampilkan form pembayaran, petugas kasir mengisi nomor meja, kemudian aplikasi desktop mengirim data meja tersebut ke

server. Server mengecek data meja yang diterima kemudian server mengambil

(54)

Gambar 3.7 Activity Diagram Proses Pembayaran

e. Activity Diagram Proses Reservasi /Booking Meja

Proses reservasi dilakukan oleh petugas kasir. Petugas kasir melayani

reservasi melalui telepon atau bisa juga dengan melayani secara langsung di

restoran. Desktop application akan menampilkan form reservasi, kemudian pelayan menginputkan data yang diperlukan untuk dilakukan reservasi/ booking/ pesan meja. Desktop application mengirimkan data reservasi tersebut ke server

untuk dilakukan pengecekan ketersediaan booking. Jika tidak tersedia, maka akan gagal reservasi. Jika tersedia server menyimpan data reservasi tersebut, kemudian menampilkan daftar reservasi pada list reservasi. Server melakukan pengecekan jadwal reservasi, apabila masuk pada 1(satu) jam sebelum jadwal yang dipesan, maka akan tampil tanda meja sedang booking/ dipesan pada mobile application

(55)

Kasir Desktop Application Server Mobile Application

Tampil Form reservasi Isi data reservasi

Mengirim data reservasi

Menyimpan data reservasi Mengecek ketersediaan booking

gagal booking

tidak tersedia

tersedia Tampil daftar reservasi

Mengecek jadwal reservasi

tampil tanda booking Masuk renatang 1 jam sebelum jadwal tidak masuk rentang1 jam sebelum jadwal

Gambar 3.8 Activity Diagram Proses Reservasi /Booking Meja

f. Activity Diagram Proses Laporan

Proses pembuatan laporan dilakukan oleh manajer. Desktop application

menampilkan tampilan aplikasi utama. Jika manager memilih laporan penjualan, kemudian pilih jenis laporan harian, maka desktop application akan meminta laporan harian ke server. Server mengambil data laporan, menampilkan laporan harian pada desktop application. Jika manajer memilih laporan berdasarkan bulanan, maka akan meminta laporan harian pada server, server mengambil data laporan bulanan yang muncul pada desktop application. Laporan bulanan dan harian menghasilkan entitas bisnis laporan. Gambar terlihat pada gambar 3.9.

(56)

3.2.3 Sequence Diagram

Sequence diagram menggambarkan kegiatan objek pada use case

dengan mendeskripsikan waktu hidup objek dan message yang dikirim dan diterima antar objek

a. Sequence Diagram Proses Login

User (Pelayan / Checker / Bagian Dapur / Kasir / Manajer) melakukan proses login pada login view setiap akan menggunakan aplikasi mobile/desktop. Proses login dilakukan dengan cara input data login (nama &password). Database

mengecek data login tersebut, ke Db helper kemudian memvalidasi data yang menghasilkan pesan login.

Gambar 3.10 Sequence Diagram Proses Login

b. Sequence Diagram Proses Pilih Meja