Analisis Performasi Web Service Api Graphql pada Domain M-Commerce Menggunakan Nodejs dan Mongodb
F-1
BIODATA Henra Setia Nugraha
Address
:
Phone
Email
:
:
Jl. Raya Subang Dusun Kayumanis RT 12/14, Desa Sukarasa, Kec.
Darma, Kab. Kuningan, Prov. Jawa Barat
+6281224099720
henra.sn@gmail.com
Informasi Personal
Place & D.O.B
Marital Status
Religion
Gender
Languages Known
: Kuningan, Desember 20th 1992
: Single
: Moslem
Male
: Sunda, Indonesian, English
Pendidikan Formal
Indonesia Computer University Teknik Informatika
SMAN 1 Kuningan
IPA
SMPN 1 Kuningan
SDN Sukarasa
2011 – 2016
2008 – 2011
2005 – 2008
1999 – 2005
ANALISIS PERFORMANSI WEB SERVICE API GRAPHQL
PADA DOMAIN M-COMMERCE MENGGUNAKAN NODEJS
DAN MONGODB
SKRIPSI
Diajukan Untuk Ujian Akhir Sarjana
HENRA SETIA NUGRAHA
10111351
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS TEKNIK DAN ILMU KOMPUTER
UNIVERSITAS KOMPUTER INDONESIA
2016
KATA PENGANTAR
Assalamualaikum Wr.Wb.
Puji dan syukur penulis panjatkan kehadirat Allah SWT atas rahmat dan
karunia-Nya sehingga penulis dapat menyelesaikan skripsi yang berjudul “Analisis
Performansi Web
Service Api GraphQL Pada Domain M-Commerce
Menggunakan Nodejs Dan Mongodb” sebagai syarat untuk menyelesaikan
program studi Strata I Jurusan Teknik Informatika Fakultas Teknik dan Ilmu
Komputer pada Universitas Komputer Indonesia.
Penyusunan skripsi ini tidak akan terwujud tanpa mendapat dukungan,
bantuan dan masukan dari berbagai pihak. Untuk itu, penulis ingin menyampaikan
terima kasih kepada:
1.
Allah SWT atas petunjuk, pertolongan, karunia, hidayah, kekuatan, kesehatan,
dan kesabaran selama menyelesaikan skripsi ini. Sholawat serta salam selalu
terlimpahkan kepada baginda Nabi Muhammad SAW.
2.
Orang tua dan keluarga tercinta, yang senantiasa memberikan doa, semangat,
motivasi, dan kasih sayangnya kepada penulis .
3.
Bapak Adam Mukharil Bactiar, S.Kom., M.T. selaku dosen pembimbing yang
telah sabar membimbing, memotivasi, memberikan perhatian dan memberikan
pengarahan selama penelitian tugas akhir ini sehingga tugas akhir ini bisa
terselesaikan dengan sebaik-baiknya.
4.
Ibu Ednawati Rainarli selaku reviewer yang telah memberikan masukan dan
arahan selama perbaikan analisis ini.
5.
Bapak Andri Heryandi, S.T., M.T. selaku selaku penguji tiga yang telah
menguji kompetensi dan memberikan masukan untuk penelitian ini.
6.
Ibu Utami dewi selaku dosen wali IF-1 angkatan 2011.
7.
Seluruh Dosen dan Staff pengajar jurusan Teknik Informatika Universitas
Komputer Indonesia.
8.
Teman-teman seperjuangan bimbingan bapak Adam Mukharil Bachtiar yang
telah berjuang bersama dalam meyelesaikan skripsi ini
iii
9.
Muhammad Rivki, Rosmaya Nurbayati, Arifin Bardansyah, Alfons Santoso
Azhari, dan Hafizha Husnaisa yang telah mensupport dalam pengerjaan
penelitian ini.
10. Teman – teman kelas IF-1 angkatan 2011 yang berjuang bersama sama kuliah.
11. Semua pihak yang terlibat dan ikut membantu dalam tugas akhir ini baik secara
langsung maupun tidak langsung.
Sangat disadari bahwa dalam pelaksanaan dan penyusunan skripsi ini masih
banyak kekurangan dan jauh dari kesempurnaan. Oleh karena itu, saran dan kritik
yang membangun sangat diharapkan untuk pengembangan ke arah yang lebih baik.
Bandung, 25 Agustus 2016
Penulis
iv
DAFTAR ISI
ABSTRAK ............................................................................................................... i
ABSTRACT ............................................................................................................ ii
KATA PENGANTAR ........................................................................................... iii
DAFTAR ISI ........................................................................................................... v
DAFTAR GAMBAR ........................................................................................... viii
DAFTAR TABEL ................................................................................................... x
DAFTAR SIMBOL .............................................................................................. xii
DAFTAR LAMPIRAN ......................................................................................... xv
BAB 1
PENDAHULUAN ................................................................................ 1
1.1
Latar Belakang Masalah................................................................................. 1
1.2
Rumusan Masalah .......................................................................................... 2
1.3
Maksud dan Tujuan........................................................................................ 3
1.4
Batasan Masalah ............................................................................................ 3
1.5
Metodologi Penelitian .................................................................................... 3
1.6
Sistematika Penulisan .................................................................................... 5
BAB 2
Landasan Teori ..................................................................................... 7
2.1
Web Service .................................................................................................. 7
2.2
Quality of Service for Web Service ............................................................. 7
2.3
GraphQL ...................................................................................................... 12
2.4
REST ............................................................................................................ 18
2.5
Android ........................................................................................................ 20
2.6
BlazeMeter ................................................................................................... 21
2.7
Heroku cloud ................................................................................................ 22
2.8
JSON ............................................................................................................ 22
v
2.9
M-Commerce ............................................................................................... 23
2.10 Object Oriented Analysis And Design ......................................................... 23
2.11 Pengujian Unit ............................................................................................. 28
BAB 3
3.1
ANALISIS DAN PERANCANGAN SISTEM .................................. 29
Analisis Domain........................................................................................... 29
3.1.1 Analisis Data .............................................................................................. 30
3.1.2 Analisis Query ............................................................................................ 33
3.1.3 Analisis Collections .................................................................................... 35
3.2
Analisis Web Service................................................................................... 37
3.2.1 Web Service API Menggunakan REST ..................................................... 37
3.2.2 GraphQL API ............................................................................................. 42
BAB 4
4.1
IMPLEMENTASI DAN PENGUJIAN SISTEM ............................... 49
Sistem Bahan Uji ......................................................................................... 49
4.1.1 Lingkungan sistem...................................................................................... 49
4.1.2 Implementasi Data ...................................................................................... 50
4.1.3 Implementasi kelas ..................................................................................... 51
4.1.4 Implementasi Prototype .............................................................................. 61
4.1.5 Dokumentasi API ....................................................................................... 63
4.2
Pengujian sistem .......................................................................................... 64
4.2.1 Rencana Pengujian ..................................................................................... 64
4.2.2 Scenario pengujian ..................................................................................... 69
4.2.3 Hasil Pengujian ........................................................................................... 78
4.2.4 Evaluasi Pengujian ..................................................................................... 90
BAB 5
kesimpulan dan saran .......................................................................... 93
5.1. Kesimpulan .................................................................................................. 93
5.2. Saran ............................................................................................................ 93
vi
Daftar Pustaka ....................................................................................................... 94
vii
DAFTAR PUSTAKA
W. Siswoutomo, Membangun Web
[1]
Service Open Source
Menggunakan PHP, Jakarta: Elex Media Komputindo, 2004.
E. C. Ortiz, “Introduction to Facebook APIs,” 10 Desember
[2]
2010.
[Online].
Available:
http://www.ibm.com/developerworks/library/x-androidfacebookapi/.
[Diakses 11 February 2016].
P. Bela, “GraphQL in the age of REST APIs,” 7 Juli 2015.
[3]
[Online].
Available:
https://medium.com/chute-
engineering/GraphQL-in-the-age-of-rest-apisb10f2bf09bba#.qbmjsrrvq. [Diakses 11 February 2016].
W. N. W. A. RAHMAN dan D. F. MEZIANE, “Challenges to
[4]
Describe QoS Requirements for Web Services Quality ,” vol. 5, p. 51,
2008.
K. Lee, J. Jeon, W. Lee, S.-H. Jeong dan S.-W. Park, “QoS for
[5]
Web
Services: Requirements and Possible Approaches,” W3C
Working Group Note 25 November 2003, [Online]. Available:
http://www.w3c.or.kr/kr-office/TR/2003/ws-QoS/.
T. Rajendran dan P. Dr. Balasubramanie, “Analysis on the
[6]
Study of QoS-Aware Web ,” Journal of Computing, vol. 1, no. 1, p.
119, 2009.
A. Mani dan A. Nagarajan, “Understanding Quality of Service
[7]
for Web Services,” Improving the performance of your Web Services,
2002.
[8]
M. I. Ladan, “Web
Services Metrics: A Survey and A
Classification,” Journal of Communication and Computer 9, 2012.
94
[9]
N. Schrock, “GraphQL Introduction,” Facebook, 1 May 2015.
[Online].
Available:
https://facebook.github.io/react/blog/2015/05/01/GraphQLintroduction.html.
[10]
F. Employee, “GraphQL,” Facebook, [Online]. Available:
https://facebook.github.io/GraphQL/.
[11]
V. Bojinov, RESTful Web
API Design with Node.js,
Birmingham B3 2PB: Packt Publishing Ltd, 2015.
[12]
A. Hanjura, Heroku Cloud Application Development,
Birmingham: Packt Publishing, 2014.
[13]
“Introducing
JSON,”
[Online].
Available:
http://www.json.org/.
[14]
H. Divayana, Konsep OOAD, Jakarta: STMIK Eresha, 2010.
[15]
J. Hermawan, Analisa Desain & Pemrograman Berorientasi
Objek dengan UML dan Visual Basic.NET, Yogyakarta: Andi, 2010.
[16]
K. Hamilton dan R. Miles, Learning UML 2.0, United States
of America: O'Reilly, 2006.
[17]
R. Osherove, The Art of Unit Testing Second Edition, Shelter
Island: Manning Publications Co, 2014.
[18]
F. Doglio, Pro REST API Development with Node.js, La Paz,
Canelones: Apress, 2015.
[19]
I. P. A. E. Pratama, E-commerce, E-Business, Mobile
Commerce, Bandung: BI-Obses, 2015.
[20]
Susila dan S. Vadivel, “QoS Measurement Tool for Web
Service Selection,” International Journal of Web Engineering, vol. 3,
no. 1, pp. 1-8, 2014.
95
BAB 1
PENDAHULUAN
1.1 Latar Belakang Masalah
Aplikasi Web saat ini berkembang pesat mulai dari front-end hingga backend, dan teknologi Web
ini mendukung perkembangan teknologi komputasi
terdistribusi (distributed computing) dimana teknologi ini memungkinkan
melakukan proses di banyak mesin, dan hasilnya dimanfaatkan oleh banyak mesin.
Salah satu dukungan teknologi Web pada komputasi terdistribusi adalah pada
pembangunan Web Service yang berfungsi sebagai aplikasi transaksi data antar
mesin yang terlibat di dalamnya. Konsep Web Service muncul untuk menjembatani
sistem-sistem informasi yang ada tanpa mempermasalahkan perbedaan platform
yang digunakan oleh masing-masing sumber [1]. Dalam pembangunan Web
Service ada beberapa teknologi yang dapat digunakan di antaranya SOAP, RESTful,
dan RPC-XML. Selain teknologi tersebut terdapat satu teknologi Web Service yakni
GraphQL, yang diciptakan dan digunakan oleh perusahaan Facebook ini mengubah
paradigma membaca dan menulis data berorientasi fungsi menjadi berorientasi
objek. Beberapa contoh objek dari facebook di antaranya adalah users, photos,
albums, dan koneksi/friendlist. Pendekatan ini membuat Facebook api lebih
sederhana dan konsisten saat bekerja dengan objek [2].
RESTful merupakan salah satu dari arsitektur-style Web Service yang
tergolong teknologi lama dan mudah untuk dipahami saat membangunnya. Namun
pada tahun 2015 teknologi baru yang diciptakan oleh perusahaan ternama yang
membidangi social media Facebook yakni GraphQL. Teknologi GraphQL ini
merupakan teknologi open source sehingga pengembang yang lain dapat ikut
mengembangkan teknologi ini. Saat ini satu-satunya kasus penggunaan produksi
GraphQL adalah Facebook. GraphQL berfungsi dengan baik untuk jejaring sosial
Facebook tetapi masih belum bisa dipastikan akan berfungsi baik pada sistem yang
lain seperti pada sistem Facebook [3]. Perusahaan Facebook kini secara perlahan
mengganti RESTful dengan GraphQL, walaupun tidak pada semua sistem dari
jejaring sosial Facebook itu sendiri. Permasalahan yang muncul yaitu perusahaan
1
2
Facebook memindahkan beberapa api dari RESTful api ke graph api. Facebook
memindahkan beberapa api ke graph api bukan tanpa alasan. Selain itu ada
beberapa penulis di situs medium.com menyatakan bahwa RESTful sudah layak
untuk digantikan oleh GraphQL dengan beberapa alasan, namun dari alasan yang
mereka tulis pada situs tersebut belum ditemukan artikel yang membahas mengenai
QoS(Quality of Service) Web Service pada GraphQL. Menurut hipotesa sementara
ada beberapa kekurangan pada teknologi RESTful, dan kekurangan tersebut dapat
diselesaikan menggunakan teknologi GraphQL api. Namun teknologi GraphQL ini
tergolong teknologi yang masih baru, belum ada pengujian secara khusus terhadap
teknologi ini.
Berdasarkan pemaparan permasalahan tersebut, didapatkan solusi yaitu
dengan membangun sebuah Web Service GraphQL untuk melakukan pengujian
performansi dan membandingkannya dengan Web Service yang menggunakan
RESTful. Salah satu objek yang dapat dijadikan sebagai sampel pengujian adalah
Web Service untuk m-commerce, karena perkembangan pada m-commerce sangat
cepat, dapat dilihat hadirnya beberapa m-commerce di Indonesia seperti lazada,
blibli, zalora, zoya, berrybenka, shopee, bhinneka.com, matahari mall, dan
bukalapak, sehingga hasil dari penelitian ini akan sangat berguna untuk beberapa
developer dalam mempertimbangkan migrasi Web Service api dari teknologi
sebelumnya ke teknologi GraphQL. Selain itu aspek yang dapat dijadikan sebagai
parameter ukur untuk perbandingan antara GraphQL dengan RESTful yakni QoS
Web Service.
1.2 Rumusan Masalah
Berdasarkan latar belakang, hal yang menjadi permasalahan adalah
hadirnya teknologi GraphQL yang tergolong baru ini belum ditemukan jurnal atau
paper yang menguji secara khusus seperti QoS, terutama pada domain m-commerce.
3
1.3 Maksud dan Tujuan
Maksud dari penelitian ini adalah menguji performansi dari teknologi
GraphQL pada domain selain sosial media yakni m-commerce. Adapun tujuan dari
penelitian ini adalah untuk melihat kualitas performance dari teknologi GraphQL,
sehingga dapat membantu developer Web Service api dalam mempertimbangkan
migrasi dari teknologi REST ke GraphQL. Dan membandingkannya menggunakan
aspek QoS Web Service sebagai parameter ukur.
1.4 Batasan Masalah
Adapun batasan masalah yang digunakan dalam penelitian ini adalah
sebagai berikut:
1. Dalam penelitian ini pembentukan query atau request data hanya yang berkaitan
dengan data produk.
2. Dalam penelitian ini melibatkan mobile device sebagai salah satu alat untuk
menguji request dan response dari server, mobile device menggunakan sistem
operasi android 4.4.4.
3. Untuk representasi data yang akan dijadikan sebagai pesan antara client-server
menggunakan format JSON.
4. Acuan pembanding antara RESTful dengan GraphQL menggunakan
karakteristik QoS yang sering digunakan [4] yakni Service time, reliability,
execution price, availability, performance , dan security, namun pada penelitian
ini security dan execution price tidak digunakan.
1.5 Metodologi Penelitian
Metodologi yang digunakan dalam penelitian ini adalah metode penelitian
komparatif yang bertujuan membandingkan antara dua objek atau lebih pada suatu
variabel tertentu. Objek yang dibandingkan dalam penelitian ini adalah GraphQL
dan RESTful dengan memperhatikan beberapa hal dari QoS Web Service. Adapun
tahapan-tahapan dalam penelitian ini sebagai berikut:
4
Analisis Domain
Analisis Fitur
Analisis Data
Analisis Query
Analisis GraphQL
API
Analisis RESTful
API
Pengujian
Gambar 1-1 Alur Penelitian
Berikut penjelasan dari setiap tahapan dalam penelitian.
1. Analisis Domain
Pada subbab ini akan dibahas mengenai beberapa hal mengenai masalah
yang terjadi pada domain kasus m-commerce, mulai dari permasalahan dari segi
mobile hingga commercenya itu sendiri.
2. Analisis Fitur
Pada subbab ini akan dijelaskan beberapa fitur yang terdapat di dalam
aplikasi m-commerce, tidak hanya fitur yang dianalisis namun data yang digunakan
pada setiap fiturpun akan dibahas. Analisis fitur ini bermaksud untuk mencari data
apa saja yang sering digunakan pada aplikasi m-commerce, setelah didapat data
yang sering digunakan, maka data tersebut akan digunakan sebagai objek . . .
3. Analisis Data
Berdasarkan hasil analisis fitur terdapat data yang sering diakses dalam mcommerce, data tersebut akan dianalisis mulai dari bentuk
4. Analisis Query
5
Pada subbab ini akan dilakukan analisis yang hampir sama dengan analisis
fitur namun perbedaannya terletak pada hasil dari analisis, target dari analisis ini
adalah dapat melihat bentuk query atau request data yang ada di dalam setiap fitur,
query yang terbentuk akan dijadikan sebagai bahan uji pada bab pengujian.
5. Analisis GraphQL API
Pada subbab ini akan dijelaskan mengenai cara kerja dari GraphQL API
menggunakan sample.
6. Analisis RESTful API
Pada tahap ini akan dilakukan analisis cara kerja dari teknologi RESTful API
dengan menggunakan sample.
7. Pengujian
Pengujian merupakan poin utama di mana penelitian mengenai analisis
performansi GraphQL dapat terlihat jelas, pada subbab ini akan dibahas mengenai
langkah-langkah pengujian Web Service api GraphQL dan RESTful. Setiap poin
dari QoS Web Service memiliki cara untuk menguji yang berbeda-beda, pada
subbab ini akan dibahas bagaimana cara pengujian pada setiap poin pada QoS Web
Service.
1.6 Sistematika Penulisan
Sistematika penulisan tugas akhir ini disusun untuk memberikan gambaran
umum mengenai penelitian yang dikerjakan. Sistematika penulisan dalam
dokumentasi skripsi ini adalah sebagai berikut:
BAB 1 PENDAHULUAN
Bab 1 akan membahas tentang latar belakang permasalahan, merumuskan
inti permasalahan yang dihadapi, mencari solusi atas masalah tersebut,
mengidentifikasi masalah tersebut, menentukan maksud dan tujuan, kegunaan
penelitian, pembatasan masalah, metode penelitian, dan sistematika penulisan.
6
BAB 2 LANDASAN TEORI
Bab 2 menguraikan bahan-bahan kajian, konsep dasar, dan teori dari para
ahli yang berkaitan dengan penelitian. Meninjau permasalahan dan hal-hal yang
berguna dari penelitian-penelitian dan sintesis serupa yang pernah dikerjakan
sebelumnya dan menggunakannya sebagai acuan pemecahan masalah pada
penelitian ini.
BAB 3 ANALISIS
Bab 3 menguraikan hasil analisis dari objek penelitian untuk mengetahui hal
atau masalah apa yang timbul dan mencoba memecahkan masalah tersebut dengan
mengaplikasikan perangkat-perangkat dan pemodelan yang digunakan.
BAB 4 PENGUJIAN SISTEM
Bab 4 menguraikan tentang perancangan solusi beserta implementasinya
dari masalah-masalah yang telah dianalisis. Pada bagian ini juga akan ditentukan
bagaimana sistem dirancang, dibangun, diuji dan disesuaikan dengan hasil
penelitian.
BAB 5 KESIMPULAN DAN SARAN
Bab 5 berisi kesimpulan dan saran yang merupakan jawaban yang melatar
belakangi masalah pada Bab 1, dan saran untuk perbaikan dan menindaklanjuti hasil
penelitian yang nantinya akan berguna bagi pengembang perangkat lunak ini ke
depannya.
BAB 2
LANDASAN TEORI
2.1 Web Service
Web Service merupakan salah satu komponen sistem terdistribusi pada SOA
(Service Oriented Architecture). Service dibangun untuk menyediakan interface
yang memproses dan mengirim pesan dalam bentuk xml atau json. Service
menggunakan object oriented untuk mendefinisikan pesan yang akan dikirim
kepada client atau Service yang lain. Selain menyediakan interface untuk menerima
dan mengirim pesan dari client atau Service lain melalui protokol (HTTP, SMTP,
TCP), Service juga menangani beberapa business logic dan beberapa operasi CRUD
di dalamnya.
2.2 Quality of Service for Web Service
Untuk membangun sebuah sistem informasi yang berukuran kecil hingga
besar diperlukan sebuah standarisasi dan mekanisme, sehingga sistem yang
dibangun memiliki kualitas yang baik, selain itu mudah untuk maintenance. Untuk
membangun sebuah sistem informasi Web Service ada beberapa standar yang harus
diperhatikan di antaranya. [5]
1. Performance
Performance merupakan salah satu hal yang sangat penting dalam dunia
teknologi karena tujuan dibangunnya sebuah teknologi diharapkan dapat membantu
pekerjaan manusia, namun tidak hanya sekedar membantu tapi mempercepat
pekerjaan, sebagai contoh dalam hal menghitung, kalkulator dapat membantu
pekerjaan menghitung dalam waktu yang jauh lebih cepat. Oleh karena itu dalam
pembangunan sistem, performance perlu perhatian khusus, mulai dari algoritma
yang digunakan, stack, hingga hardware yang akan menjalankan sistem yang
dibangun.
7
8
Pengukuran performance
pada QoS Web
Service lebih fokus pada
pengukuran throughput, response time, dan latency [6] [7] [8].
Throughput
merepresentasikan permintaan/satuan waktu, dimana throughput ini mengukur
seberapa banyak request yang ditangani atau di-handle oleh server secara periodik.
Response time mengukur berapa lama server mengirimkan data kepada client.
Latency mengukur waktu delay antara waktu client melakukan request dan waktu
ketika client mendapatkan response dari server.
Gambar 2-1 Client Server Transaction
1. Throughput
Pengukuran throughput dapat dilakukan dengan cara melakukan lebih dari
satu request dalam kurun waktu tertentu dan dalam dilakukan secara bersamaan.
Untuk mendapatkan nilai maksimal throughput dapat menggunakan rumus sebagai
berikut:
Maksimal throughput =
�ℎ
�
�
�
� ��
� ��
... persamaan(2.1)
Proses pengukuran nilai maksimal throughput dapat dilakukan dengan
melakukan logging atau pencatatan jumlah request yang di-handle oleh server
dalam kurun waktu tertentu.
9
2. Latency
Pengukuran waktu latency merupakan waktu delay dimana client menunggu
response yang diberikan oleh server. Untuk mendapatkan nilai waktu delay dapat
menggunakan rumus sebagai berikut:
Latency = response time – request time ................................ persamaan(2.2)
Pengukuran latency dapat dilakukan dengan cara melakukakan logging atau
pencatatan pada client, yang dapat dicatat adalah waktu ketika client melakukan
request ke server dan waktu ketika client mendapatkan response dari sever. Setelah
waktu tersebut didapatkan, maka rumus diatas dapat digunakan untuk mendapatkan
nilai latency.
3. Response Time
Pada pengukuran ini merupakan perhitungan waktu yang diperlukan untuk
menyelesaikan request. Waktu yang dihitung adalah waktu dimana server
melakukan execution time dan memberikan response kepada client. Untuk
mendapatkan nilai response time dapat menggunakan rumus sebagai berikut:
Response time = execution time + data transferred time ......... persamaan(2.3)
Data transfer time merupakan waktu dimana server mengirimkan data json
ke client. Pengukuran ini juga dapat menggunakan logging atau pencatatan, waktu
yang dicatat adalah waktu yang diperlukan untuk business logic yang didapat dari
waktu ketika server mendapatkan request hingga business logic selesai dilakukan,
dan waktu yang diperlukan untuk mengirim data ke client yang didapat dari waktu
business logic selesai dilakukan hingga data tersebut sampai di client.
Parameter qualitas performance pada Web Service dapat dilihat dari empat
point yang telah dijabarkan sebelumnya yakni throughput, response time, latency
10
dan execution time. Web Service yang memiliki performance yang baik dapat
diliha dari throughput yang cepat, latency yang rendah, response yang cepat, dan
execution cepat.
2. Reliability
Reliability merupakan tolak ukur untuk tingkat maintain Web Service.
Mengukur tingkat kegagalan pada sistem setiap hari, minggu, bulan, atau tahun
tergantung dari seberapa besar kemampuan pengembang untuk melakukan
maintain. Karena tidak ada jaminan semua pesan atau response akan sampai ke
tujuan.
3. Scalability
Dalam pembangunan sebuah sistem akan dimulai dari prototype di mana
sistem belum siap untuk digunakan secara utuh, karena beberapa fungsi masih
memiliki error atau bug. Setelah semuanya fungsional dapat dijalankan sesuai
dengan harapan developer tidak akan berhenti untuk mengembangkan lagi sistem
yang telah dibangun, oleh karena itu sistem sangat dituntut untuk dapat
dikembangkan menjadi sistem yang sesuai dengan kebutuhan saat itu. Misalnya
dalam meningkatkan kemampuan sistem dalam memproses setiap request dari user
yang semakin meningkat jumlahnya.
4. Capacity
Web Service saat ini salah satu distributed system yang sering digunakan
untuk transaksi data, client atau system yang menggunakan layanan dari Web
Service tersebut bermacam-macam dari Web , desktop application, hingga mobile.
Pada kasus m-commerce saat ini sudah banyak aplikasi yang menyediakan layanan
untuk membeli barang secara online atau pengguna dapat menjadi penjual untuk
pengguna lainnya. Pengguna pada aplikasi lazada telah mencapai lebih dari sepuluh
juta download, dengan demikian Web Service lazada harus mampu untuk menghandle request dari pengguna yang begitu banyak dalam waktu yang bersamaan.
5. Robustness
11
Request client yang memiliki parameter untuk diproses di dalam server
yang terkadang ada beberapa parameter tidak memiliki nilai yang berakibat
kesalahan pada sistem yang dikarenakan human error dari pengguna atau validasi
pada sistem masih kurang dan sistem Web Service dituntut untuk dapat menangani
masalah tersebut.
6. Exception Handling
Dalam pembangunan sistem memungkinkan beberapa hal yang tidak
terprediksi dapat terjadi. Contoh sederhana dalam hal request, client akan
melakukan request ke server dengan beberapa parameter, namun tidak semua
parameter bersifat required, maka server harus mampu untuk menanggulangi jika
ada parameter yang tidak bersifat required tidak memiliki nilai.
7. Accuracy
Akurasi merupakan hal penting dalam sistem informasi, namun di sini
maksud dari akurasi adalah tingkat kesalahan yang dihasilkan oleh layanan Web .
8. Integrity
Integrity salah satu hal yang wajib ada di dalam Web
Service untuk
mencegah unauthorized access atau modifikasi pada sistem atau data. Ada dua tipe
integrity yakni data integrity dan transactional integrity. Data integrity memastikan
apakah data yang di transfer telah dimodifikasi ketika transit. Sedangkan
transactional integrity mengacu pada prosedur yang menjamin menjaga database
integrity dalam transaksi.
9. Accessibility
Client dari Web Service tidak hanya satu jenis, ada beberapa jenis client
yakni mobile, desktop, maupun Service lainnya. Jadi Web Service harus mampu
untuk melayani setiap request yang berbeda-beda.
10. Availability
12
Pembangunan Web Service api tidak semata-mata dibangun dari awal
sebuah startup atau perusahaan dari awal, terkadang pembangunan Web Service
dibangun di tengah jalan dengan alasan permintaan dari pengguna atau ekspansi
dari perusahaan itu sendiri ataupun rencana untuk membangun sistem terintegrasi.
Maka dari itu Web Service harus mampu tersedia sesegera mungkin untuk berbagai
keperluan dalam integrase ataupun ekspansi.
11. Interoperability
Dalam pembangunan sebuah sistem informasi khususnya Web Service tidak
hanya memikirkan masalah bahasa pemrograman yang digunakan namun ada
beberapa hal seperti sistem dari database. Tidak hanya itu developer juga harus
memikirkan bagaimana untuk menggunakan sistem dari database di dalam Web
Service yang dibangun. Selain database ada juga sistem lain yakni jalur komunikasi
seperti http protocol. Jadi Web
Service harus memiliki kemampuan untuk
berinteraksi dengan sistem lain tanpa akses yang rumit.
12. Security
Salah satu media sosial dunia yakni facebook memiliki jutaan data pribadi
mengenai penggunanya di seluruh dunia. Data tersebut bersifat rahasia, tidak
sembarang orang atau kelompok dapat mengakses data tersebut. Sehingga
perusahaan facebook harus mampu untuk menjaga semua data dari setiap
penggunanya. Kini facebook telah menyediakan Service untuk perusahaan atau
aplikasi lain agar dapat mengakses akun tertentu dengan beberapa kebijakan dari
facebook untuk menjaga data pengguna agar tidak semua data dapat diambil begitu
saja. Maka dari itu Web Service yang dibangun harus memiliki sistem keamanan
seperti authentication, authorization, confidentiality, traceability and auditability,
data encryption, non-repudation.
2.3 GraphQL
GraphQL maupun REST tidak terpaku pada database yang digunakan, pada
dasarnya Web Service mengambil sejumlah data dari database yang nantinya akan
13
di proyeksikan ke dalam bentuk API. Prinsip-prinsip yang digunakan GraphQL
untuk membuat suatu interface atau API sebagai berikut: [9]
1. Hierarchical
GraphQL menggunakan hierarki untuk relasi antar objek, seperti halnya
dalam REST menggunakan join statement pada SQL.
2. Client Specified Queries
Pada GraphQL setiap client request untuk data fetching atau data
manupulate
menggunakan query yang di dalamnya berisi model data yang
dibutuhkan, berbeda dengan REST, semuanya ketentuan data yang akan disajikan
dalam API sudah ditentukan, karena konsep everything is resource pada REST.
3. Backward Compabilities
Setiap mobile application minimal dalam tiga bulan akan diperbaharui, pada
kasus ini setiap melakukan request data ada kemungkinan berbeda-beda setiap
client, karena tidak semua client akan memperbaharui aplikasinya. sehingga
GraphQL dari itu setiap melakukan requent data ke GraphQL menggunakan
specified query bukan resource.
4. Strongly Typed
Ketika client mengirim request dengan query, setiap item yang ada di dalam
objek query akan di cek satu per satu apakah data yang di-request tersedia atau
tidak, jika tidak tersedia maka GraphQL akan membuat pesan error sebelum query
di eksekusi.
GraphQL dibangun dalam waktu yang cukup lama, karena pembangunan
GraphQL ini diharapkan dapat menyelesaikan beberapa permasalahan pada kasus
tertentu. [10]
1. Operation
14
Teknologi GraphQL memiliki dua buah operasi yang akan digunakan
sebagai alat untuk transaksi data client-server yakni query dan mutation, query
hanya digunakan untuk fetching data sedangkan mutation digunakan untuk
modifikasi data.
2. Selection Set
Selection set merupakan sebuah set informasi yang dibutuhkan oleh client,
dalam selection set dapat berisi Field, FragmentSpread, atau InlineFragment. Dan
client akan mendapatkan data yang sama persis dengan selection set yang dikirim
ke server. Berikut contoh bentuk dari selection set.
{
id
nama
epan
namaBelakang
}
Gambar 2-2 Selection Set
3. Field
Sebuah selection set terbentuk dari satu atau beberapa field. Sebuah field
menjelaskan satu informasi. Kumpulan field dalam satu selection set menjelaskan
data yang kompleks atau keterhubungan dengan data yang lain. Untuk mendapatkan
data yang lebih kompleks dalam data, memungkinkan dalam sebuah field berisi
selection set. Semua operasi pada GraphQL harus menentukan selections pada field
yang mengembalikan nilai scalar untuk memastikan response yang didapat jelas.
15
{
me {
id
firstName
lastName
birthday {
month
day
}
friends {
name
}
}
}
Gambar 2-3 Field
Field di level pertama pada selection set menandakan informasi yang dapat
diakses secara global dari client dan informasi tersebut merupakan informasi client
utama atau current viewer.
4. Arguments
Secara konsep field merupakan sebuah functions yang mengembalikan nilai,
dan dalam beberapa kasus field menerima argument yang dapat mengubah nilai dari
hasil request. Sebagai contoh client akan me-request data user dengan id 4 dengan
spesifikasi profile picture dengan ukuran 100 x 100,
{
user(id: 4) {
id
nama
profilePic(size: 100)
}
}
Gambar 2-4 Arguments
5. Field Alias
16
Secara default objek dari response akan menggunakan nama field. Namun
nama field yang digunakan juga diganti dengan nama alias sesuai dengan
kebutuhan, nama alias digunakan untuk mempermudah dalam pembacaan data
response dan menghindari duplikat key. Berikut contoh dari penggunaan alias.
{
user(id: 4) {
id
name
smallPic: profilePic(size: 64)
bigPic: profilePic(size: 1024)
}
}
Gambar 2-5 Field Alias
Dari objek request tersebut maka response dari server akan berbentuk
seperti berikut.
{
"user": {
"id": 4,
"name": "Mark Zuckerberg",
"smallPic": "https://cdn.site.io/pic-4-64.jpg",
"bigPic": "https://cdn.site.io/pic-4-1024.jpg"
}
}
Gambar 2-6 Result Field Alias
6. Fragments
Fragment merupakan unit utama dalam komposisi GraphQL. Fragment
memungkinkan untuk menggunakan selections berulang kali pada sebuah field.
Inline fragment dapat digunakan di dalam selection . . . . . .
17
query noFragments {
user(id: 4) {
friends(first: 10) {
id
name
profilePic(size: 50)
}
mutualFriends(first: 10) {
id
name
profilePic(size: 50)
}
}
}
Gambar 2-7 Without Fragment
Selection set friends dan mutualFriend memiliki field yang sama, maka
selection set ini dapat dimasukkan ke dalam sebuah fragment.
query withFragments {
user(id: 4) {
friends(first: 10) {
. . .friendFields
}
mutualFriends(first: 10) {
. . .friendFields
}
}
}
fragment friendFields on User {
id
name
profilePic(size: 50)
}
Gambar 2-8 With Fragment
Memakai fragment menggunakan operator ( . . . ). Semua field yang berada
di dalam fragment akan dimasukkan ke dalam field query yang menggunakan
fragment. Fragment juga dapat diaplikasikan pada multiple levels fragment, berikut
contoh dari multiple level.
18
query withNestedFragments {
user(id: 4) {
friends(first: 10) {
. . .friendFields
}
mutualFriends(first: 10) {
. . .friendFields
}
}
}
fragment friendFields on User {
id
name
. . .standardProfilePic
}
fragment standardProfilePic on User {
profilePic(size: 50)
}
Gambar 2-9 Profile Picture Fragment
2.4 REST
REST mendefinisikan satu set prinsip arsitektur di mana dapat digunakan
untuk mendisain Web Service yang berfokus pada resource sistem, termasuk
bagaimana resource memiliki alamat (URL address) dan dapat dikirim kepada
client yang memiliki bahasa yang berbeda-beda. Interaksi antara client dengan
server menggunakan interface yang bisa diakses oleh protokol http yang sering
disebut sebagai API (Application Programming Interface). Dikarenakan
pembangunan Service untuk interaksi atau manipulasi data menggunakan bahasa
native dari SQL database yaitu insert, select, update, delete, maka verb yang
digunakan ada empat di antaranya post, get, put, dan delete. Dalam pembangunan
RESTful Web Service api's ada beberapa prinsip yang digunakan, di antaranya: [11]
1. Each resource is identifiable by a unique
Jumlah resource pada suatu sistem lebih dari satu, dan untuk mengakses
resource tersebut diperlukan URI, namun URI harus bersifat unik sama halnya
19
dengan nomor ktp, satu sama lain harus berbeda untuk mengidentifikasi pemilik
dari nomor ktp tersebut.
2. User the standard HTTP methods
Http protocol memiliki delapan verb yaitu sebagai berikut:
1. GET
2. POST
3. PUT
4. DELETE
5. HEAD
6. OPTIONS
7. TRACE
8. CONNECT
Pada teknologi RESTful ini tidak semua verb HTTP digunakan, hanya empat
yang digunakan di antaranya
Tabel 2-1 Verb RESTful
HTTP Verb
GET
Action
Kode status respon
Request terhadap
“200 OK”, jika resource tersedia, “404 Not
resource yang sudah ada
Found”, jika resource tidak tersedia, dan “500
Intenal Server Error”, jika terdapat kesalahan di
dalam server.
PUT
Memasukan data
memperbaharui data
atau
“201 CREATED”, jika data telah masuk ke dalam
database, “200 OK”, jika data telah diperbaharui,
“500 Intenal Server Error”, jika terdapat kesalahan
di dalam server.
POST
Memperbaharui data
“200 OK”, jika data telah diperbaharui, “500
Intenal Server Error”, jika terdapat kesalahan di
dalam server.
DELETE
Menghapus data
“200 OK”, jika resource terhapus, “404 Not
Found”, jika resource yang akan dihapus tidak
tersedia, dan “500 Intenal Server Error”, jika
terdapat kesalahan di dalam server.
20
3. Resource can have multiple representations
REST dapat mendukung beberapa format data representasi tergantung pada
request yang dilakukan, selama server mendukung format tersebut.
2.5 Android
Android merupakan sebuah sistem operasi yang berjalan dia atas linux
karnel, sistem operasi ini diterapkan pada mobile device seperti smartphone,
komputer tablet, dan smartwatch, tidak hanya mobile device android telah
digunakan pada kendaraan roda empat dan television. Android pertama kali
dikembangkan oleh Android Inc., dan pada tahun 2005 Google membeli dan
mengembangkannya hingga saat ini.
Android memiliki paradigma pemrograman yang berbeda dengan
pemrograman pada umumnya dimana dalam pemrograman java, method yang
pertama kali dijalankan adalah main(), sedangkan pada android menjalankan kode
dalam method Activity dengan menerapkan callback tertentu yang sesuai dengan
tahap tertentu dari siklus hidup. siklus hidup berguna untuk memastikan aplikasi
tidak
menghabiskan
sumber
daya
baterai.
Gambar 2-10 Android Lifecycle
Terdapat beberapa state dalam siklus hidup android yang terjadi seperti
diilustrasikan pada Gambar 2-10 Android Lifecycle
21
1. Created
Sebuah aplikasi pertama kali dijalankan dan mengeksekusi method onCreate()
termasuk menginisialisasi komponen tampilan.
2. Started
State ini secara langsung akan diakses setelah onCreate() dijalankan, dan ketika
aplikasi dijalankan setelah aplikasi tersebut di tutup.
3. Resumed
State resumed akan dijalankan setelah state paused. state ini akan menjalankan
perintah yang ada di dalam method onResume()..
4. Paused
Pada state ini semua aktivitas dalam aplikasi akan dihentikan sementara. state
ini berjalan ketika ada aplikasi yang berjalan dengan prioritas lebih tinggi.
aplikasi tidak bisa menerima input dari user dan tidak bisa mengeksekusi
perintah kode program.
5. Stopped
Pada state ini aplikasi dalam keadaan mati, tetapi background Service tetap
berjalan.
6. Destroyed
Aplikasi benar - benar mati, tidak ada proses apapun yang berjalan termasuk
background Service.
2.6 BlazeMeter
Pengujian performance menggunakan acuan QoS Web Service dapat
dilakukan dengan menggunakan salah satu tool BlazeMeter. Tool BlazeMeter
berbasis cloud untuk mempermudah pengujian. BlazeMeter memiliki fitur yang
dibutuhkan untuk menguji performance
di antaranya fitur response time,
thoughput, dan delay. Dalam menguji performance BlazeMeter mengeksekusi
client dan server pada cloud, sehingga ketika melakukan pengujian BlazeMeter
dapat ditutup atau melakukan pengujian yang lainya. Selain itu BlazeMeter juga
dapat dikonfigurasi sesuai dengan kebutuhan mulai dari jumlah user virtual yang
22
akan digunakan untuk mengakses Service api, jumlah iteration untuk request, waktu
yang digunakan untuk menguji Web Service api, dan jumlah waktu delay antar
requet untuk satu user virtual. Hasil pengujian disajikan dengan grafik dan data
numerik untuk setiap mengujian secara detail.
2.7 Heroku cloud
Heroku merupakan salah satu penyedia platform-as-a-Service (PaaS)
terkemuka di bisnis cloud software, yang membuktikan dirinya sebagai solusi PaaS
terkemuka untuk perusahaan kecil dan besar. Dengan peningkatan yang konsisten
dan filosofinya kenyamanan melebihi konfigurasi, menjadikan developer untuk
fokus dalam menulis aplikasi Web . Hal yang bersangkutan dengan server, building,
deploying, running, dan scaling aplikasi akan diatasi oleh Heroku.
Heroku menyediakan dukungan platform untuk Ruby, Ruby on Rails, Java,
Node.js, Clojure, Scala, Python, dan PHP. Arsitektur Heroku add-on
memungkinkan developer menyesuaikan penggunaan berbagai paket pihak ketiga
berdasarkan kebutuhan. Developer memiliki fleksibilitas untuk memilih plan basic
atau premium berdasarkan kebutuhan Web site. Developer juga bisa mempercepat
aplikasi dengan menambahkan resources seperti memcached untuk caching data,
sehingga menciptakan aplikasi yang powerful yang kaya dengan fitur [12].
2.8 JSON
Interaksi antara client dengan server mempunyai banyak cara, salah satu
cara yang cukup familiar adalah interaksi yang menggunakan interface antara satu
sistem dengan sistem lainnya yang memiliki platform yang berbeda ataupun sama,
atau sering disebut sebagai API(Application Promgramming Interface). Sebuah
interaksi memiliki min satu pesan didalamnya, format pesan yang sering digunakan
dalam interaksai client-server adalah xml dan json. Json merupakan salah satu
format tulisan yang ringan, mudah dibaca oleh manusia ataupun mesin, dan mudah
bagi mesin untuk men-genterate atau untuk memecahkan atau mengubah menjadi
bentuk lain sesuai dengan kebutuhan dari satu pesan json. [13]
23
2.9 M-Commerce
Perkembangan dalam bidang penjualan semakin meningkat sejak hadirnya
penjualan online atau dapat disebut sebagai e-commerce. Banyak kalangan
memulai usaha dengan mengandalalkan e-commerce, karena tidak perlu membeli
atau menyewa bangunan untuk sebuah toko, cukup dengan membuat sistem
penjualan online atau e-commerce penjual cukup diam di rumah dan sediakan satu
ruangan sebagai gudang. E-comnmerce memiliki beberapa jenis berdasarkan peran
di dalamnya, yaitu B2B (Business to Business), B2C (Business to Client), C2C
(Clinet to Client).
2.10
Object Oriented Analysis And Design
Analisis dan desain berorientasi objek adalah cara baru dalam memikirkan
satu masalah dengan menggunakan model yang dibuat menurut konsep sekitar
dunia nyata. Tujuan dari analisis berorientasi objek adalah untuk mengembangkan
model yang menggambarkan perangkat lunak komputer karena bekerja untuk
memenuhi seperangkat persyaratan yang ditentukan usir [14]. Tools yang dapat
digunakan pada pendekatan analisis pengembangan sistem secara objek yaitu
menggunakan UML.
Unified Modelling Language (UML) adalah sebuah bahasa yang telah
menjadi
standar
dalam
industri
untuk
visualisasi,
merancang
dan
mendokumentasikan sistem piranti lunak. UML menggunakan class dan operation
object dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak
dalam bahasa bahasa berorientasi objek [15]. Dalam membangun block UML ada
tiga hal yang harus diperhatikan, yaitu object (memodelkan konsep), relationship
(menghubungkan object), dan diagram (grouping yang saling menghubungkan
antara object dan relationship. Diagram yang umum dipakai dalam analisis dan
desain adalah:
1. Use Case Diagram
Use Case Diagram menggambarkan fungsionalitas yang diharapkan dari
sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan
“bagaimana”. Sebuah Use case merepresentasikan sebuah interaksi antara aktor
24
dengan sistem. Sebuah use case dapat meng-include fungsionalitas use case lain
sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use
case yang di-include akan dipanggil setiap kali use case yang meng-include
dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use
case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik
keluar fungsionalitas yang serupa. Sebuah use case juga dapat meng-extend usecase
lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case
menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.
Dasar menentukan sebuah use case adalah use case merupakan sesuatu yang
menyediakan beberapa hasil terukur kepada pengguna atau sistem eksternal. Use
case harus memiliki sangat jelas kriteria lulus / gagal. Pengembang, tester, penulis
teknis, dan pengguna harus secara eksplisit tahu apakah sistem memenuhi kasus
penggunaan atau tidak. Setiap bagian dari use case yang memenuhi tes sederhana
ini mungkin menjadi kandidat yang baik untuk use Chase. Dasar pembangunan use
case diagram dapat dilihat pada Gambar 2-11 Dasar Pembangunan Use Case
Diagram.
Gambar 2-11 Dasar Pembangunan Use Case Diagram
2. Use Case Scenario
Sebuah diagram yang menunjukkan use case dan aktor mungkin menjadi titik
awal yang bagus, tetapi tidak memberikan detail yang cukup untuk desainer sistem
untuk benar-benar memahami persis bagaimana sistem dapat terpenuhi. Cara
terbaik untuk mengungkapkan informasi penting ini adalah dalam bentuk
penggunaan use case scenario berbasis teks per use casenya. Berikut adalah dasar
25
format penulisan use case scenario [16]. Dasar pembangunan use case scenario
dapat dilihat pada Error! Reference source not found..
Tabel 2-2 Dasar Pembangunan Use Case Scenario
Use Case Name
Goal In Context
Description
Related Use Case
Successful
End
Condition
Failed End Condition
Actors
Trigger
Main Flow
Extension
Berisi nama dari use case yang akan digunakan
Menjelaskan apa yang aktor coba untuk dapatkan
dari use case
Menjelaskan gambaran dari use case
Daftar use case yang berhubungan dengan use case
tersebut
Kondisi use case jika berhasil
Kondisi use case jika gagal
Daftar aktor yang dapat mengakses use case
Aktifitas yang dilakukan untuk mengawali use case
Step Action
1
Deskripsi urutan aksi dari aktifitas use case
2
Step Branching Action
2.1
Deskripsi urutan aksi lain selain urutan aksi
utama
3. Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di
sekitar sistem berupa message yang digambarkan terhadap waktu. Sequence
diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek
yang terkait). Sequence diagram biasa digunakan untuk menggambarkan skenario
atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event
untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas
tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa
yang dihasilkan.
Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message
digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase
desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class.
Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali
dengan diterimanya sebuah message [15]. Untuk objek-objek yang memiliki sifat
khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller
dan persistent entity. Dasar pembangunan sequence diagram dapat dilihat pada
Gambar 2-12 Dasar Pembangunan Sequence Diagram.
26
Gambar 2-12 Dasar Pembangunan Sequence Diagram
4. Class Diagram
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan
sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek.
Class
menggambarkan
keadaan
(atribut/properti)
satu
sistem,
sekaligus
menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). Class
diagram menggambarkan struktur dan deskripsi class, package dan objek beserta
hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.
Class memiliki tiga area pokok:
a. Nama dan stereotype
b. Atribut
c. Metoda
Atribut dan metoda dapat memiliki salah satu sifat berikut:
a. Private, tidak dapat dipanggil dari luar class yang bersangkutan.
b. Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak
yang mewarisinya.
c. Public, dapat dipanggil oleh siapa saja.
Class dapat merupakan implementasi dari sebuah interface, yaitu class
abstrak yang hanya memiliki metoda. Interface tidak dapat langsung
diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class.
27
Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi
package. Kita juga dapat membuat diagram yang terdiri atas package.
Class memiliki tipe-tipe relationship, diantaranya:
a. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class
yang memiliki atribut berupa class lain, atau class yang harus mengetahui
eksistensi class lain.
b. Agregasi, yaitu hubungan yang menyatakan bagian terdiri atas dimana ketika
satu class di share atau direferensikan kepada objek yang ada di class lain.
c. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari
class lain dan mewarisi semua atribut dan metoda class asalnya dan
menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang
diwarisinya. Kebalikan dari pewarisan adalah generalisasi.
d. Komposisi, yaitu jenis relasi class diagram yang kuat dimana jika sebuah class
tidak bisa berdiri sendiri dan harus merupakan bagian dari class yang lain,
maka class tersebut memiliki relasi Composition terhadap class tempat dia
bergantung tersebut. Sebuah relationship composition digambarkan sebagai
garis dengan ujung berbentuk jajaran genjang berisi/solid.
e. Depedensi, salah satu jenis relasi class diagram yang lemah dimana objek
dalam suatu class akan bekerja sangat singkat dengan objek yang ada pada class
lain.
Gambar 2-13 Dasar Pembangunan Class Diagram
5. Activity Diagram
28
Activity diagram menggambarkan berbagai alur aktivitas dalam sistem yang
sedang dirancang, bagaimana masing-masing aliran berawal, decision yang
mungkin terjad
BIODATA Henra Setia Nugraha
Address
:
Phone
:
:
Jl. Raya Subang Dusun Kayumanis RT 12/14, Desa Sukarasa, Kec.
Darma, Kab. Kuningan, Prov. Jawa Barat
+6281224099720
henra.sn@gmail.com
Informasi Personal
Place & D.O.B
Marital Status
Religion
Gender
Languages Known
: Kuningan, Desember 20th 1992
: Single
: Moslem
Male
: Sunda, Indonesian, English
Pendidikan Formal
Indonesia Computer University Teknik Informatika
SMAN 1 Kuningan
IPA
SMPN 1 Kuningan
SDN Sukarasa
2011 – 2016
2008 – 2011
2005 – 2008
1999 – 2005
ANALISIS PERFORMANSI WEB SERVICE API GRAPHQL
PADA DOMAIN M-COMMERCE MENGGUNAKAN NODEJS
DAN MONGODB
SKRIPSI
Diajukan Untuk Ujian Akhir Sarjana
HENRA SETIA NUGRAHA
10111351
PROGRAM STUDI TEKNIK INFORMATIKA
FAKULTAS TEKNIK DAN ILMU KOMPUTER
UNIVERSITAS KOMPUTER INDONESIA
2016
KATA PENGANTAR
Assalamualaikum Wr.Wb.
Puji dan syukur penulis panjatkan kehadirat Allah SWT atas rahmat dan
karunia-Nya sehingga penulis dapat menyelesaikan skripsi yang berjudul “Analisis
Performansi Web
Service Api GraphQL Pada Domain M-Commerce
Menggunakan Nodejs Dan Mongodb” sebagai syarat untuk menyelesaikan
program studi Strata I Jurusan Teknik Informatika Fakultas Teknik dan Ilmu
Komputer pada Universitas Komputer Indonesia.
Penyusunan skripsi ini tidak akan terwujud tanpa mendapat dukungan,
bantuan dan masukan dari berbagai pihak. Untuk itu, penulis ingin menyampaikan
terima kasih kepada:
1.
Allah SWT atas petunjuk, pertolongan, karunia, hidayah, kekuatan, kesehatan,
dan kesabaran selama menyelesaikan skripsi ini. Sholawat serta salam selalu
terlimpahkan kepada baginda Nabi Muhammad SAW.
2.
Orang tua dan keluarga tercinta, yang senantiasa memberikan doa, semangat,
motivasi, dan kasih sayangnya kepada penulis .
3.
Bapak Adam Mukharil Bactiar, S.Kom., M.T. selaku dosen pembimbing yang
telah sabar membimbing, memotivasi, memberikan perhatian dan memberikan
pengarahan selama penelitian tugas akhir ini sehingga tugas akhir ini bisa
terselesaikan dengan sebaik-baiknya.
4.
Ibu Ednawati Rainarli selaku reviewer yang telah memberikan masukan dan
arahan selama perbaikan analisis ini.
5.
Bapak Andri Heryandi, S.T., M.T. selaku selaku penguji tiga yang telah
menguji kompetensi dan memberikan masukan untuk penelitian ini.
6.
Ibu Utami dewi selaku dosen wali IF-1 angkatan 2011.
7.
Seluruh Dosen dan Staff pengajar jurusan Teknik Informatika Universitas
Komputer Indonesia.
8.
Teman-teman seperjuangan bimbingan bapak Adam Mukharil Bachtiar yang
telah berjuang bersama dalam meyelesaikan skripsi ini
iii
9.
Muhammad Rivki, Rosmaya Nurbayati, Arifin Bardansyah, Alfons Santoso
Azhari, dan Hafizha Husnaisa yang telah mensupport dalam pengerjaan
penelitian ini.
10. Teman – teman kelas IF-1 angkatan 2011 yang berjuang bersama sama kuliah.
11. Semua pihak yang terlibat dan ikut membantu dalam tugas akhir ini baik secara
langsung maupun tidak langsung.
Sangat disadari bahwa dalam pelaksanaan dan penyusunan skripsi ini masih
banyak kekurangan dan jauh dari kesempurnaan. Oleh karena itu, saran dan kritik
yang membangun sangat diharapkan untuk pengembangan ke arah yang lebih baik.
Bandung, 25 Agustus 2016
Penulis
iv
DAFTAR ISI
ABSTRAK ............................................................................................................... i
ABSTRACT ............................................................................................................ ii
KATA PENGANTAR ........................................................................................... iii
DAFTAR ISI ........................................................................................................... v
DAFTAR GAMBAR ........................................................................................... viii
DAFTAR TABEL ................................................................................................... x
DAFTAR SIMBOL .............................................................................................. xii
DAFTAR LAMPIRAN ......................................................................................... xv
BAB 1
PENDAHULUAN ................................................................................ 1
1.1
Latar Belakang Masalah................................................................................. 1
1.2
Rumusan Masalah .......................................................................................... 2
1.3
Maksud dan Tujuan........................................................................................ 3
1.4
Batasan Masalah ............................................................................................ 3
1.5
Metodologi Penelitian .................................................................................... 3
1.6
Sistematika Penulisan .................................................................................... 5
BAB 2
Landasan Teori ..................................................................................... 7
2.1
Web Service .................................................................................................. 7
2.2
Quality of Service for Web Service ............................................................. 7
2.3
GraphQL ...................................................................................................... 12
2.4
REST ............................................................................................................ 18
2.5
Android ........................................................................................................ 20
2.6
BlazeMeter ................................................................................................... 21
2.7
Heroku cloud ................................................................................................ 22
2.8
JSON ............................................................................................................ 22
v
2.9
M-Commerce ............................................................................................... 23
2.10 Object Oriented Analysis And Design ......................................................... 23
2.11 Pengujian Unit ............................................................................................. 28
BAB 3
3.1
ANALISIS DAN PERANCANGAN SISTEM .................................. 29
Analisis Domain........................................................................................... 29
3.1.1 Analisis Data .............................................................................................. 30
3.1.2 Analisis Query ............................................................................................ 33
3.1.3 Analisis Collections .................................................................................... 35
3.2
Analisis Web Service................................................................................... 37
3.2.1 Web Service API Menggunakan REST ..................................................... 37
3.2.2 GraphQL API ............................................................................................. 42
BAB 4
4.1
IMPLEMENTASI DAN PENGUJIAN SISTEM ............................... 49
Sistem Bahan Uji ......................................................................................... 49
4.1.1 Lingkungan sistem...................................................................................... 49
4.1.2 Implementasi Data ...................................................................................... 50
4.1.3 Implementasi kelas ..................................................................................... 51
4.1.4 Implementasi Prototype .............................................................................. 61
4.1.5 Dokumentasi API ....................................................................................... 63
4.2
Pengujian sistem .......................................................................................... 64
4.2.1 Rencana Pengujian ..................................................................................... 64
4.2.2 Scenario pengujian ..................................................................................... 69
4.2.3 Hasil Pengujian ........................................................................................... 78
4.2.4 Evaluasi Pengujian ..................................................................................... 90
BAB 5
kesimpulan dan saran .......................................................................... 93
5.1. Kesimpulan .................................................................................................. 93
5.2. Saran ............................................................................................................ 93
vi
Daftar Pustaka ....................................................................................................... 94
vii
DAFTAR PUSTAKA
W. Siswoutomo, Membangun Web
[1]
Service Open Source
Menggunakan PHP, Jakarta: Elex Media Komputindo, 2004.
E. C. Ortiz, “Introduction to Facebook APIs,” 10 Desember
[2]
2010.
[Online].
Available:
http://www.ibm.com/developerworks/library/x-androidfacebookapi/.
[Diakses 11 February 2016].
P. Bela, “GraphQL in the age of REST APIs,” 7 Juli 2015.
[3]
[Online].
Available:
https://medium.com/chute-
engineering/GraphQL-in-the-age-of-rest-apisb10f2bf09bba#.qbmjsrrvq. [Diakses 11 February 2016].
W. N. W. A. RAHMAN dan D. F. MEZIANE, “Challenges to
[4]
Describe QoS Requirements for Web Services Quality ,” vol. 5, p. 51,
2008.
K. Lee, J. Jeon, W. Lee, S.-H. Jeong dan S.-W. Park, “QoS for
[5]
Web
Services: Requirements and Possible Approaches,” W3C
Working Group Note 25 November 2003, [Online]. Available:
http://www.w3c.or.kr/kr-office/TR/2003/ws-QoS/.
T. Rajendran dan P. Dr. Balasubramanie, “Analysis on the
[6]
Study of QoS-Aware Web ,” Journal of Computing, vol. 1, no. 1, p.
119, 2009.
A. Mani dan A. Nagarajan, “Understanding Quality of Service
[7]
for Web Services,” Improving the performance of your Web Services,
2002.
[8]
M. I. Ladan, “Web
Services Metrics: A Survey and A
Classification,” Journal of Communication and Computer 9, 2012.
94
[9]
N. Schrock, “GraphQL Introduction,” Facebook, 1 May 2015.
[Online].
Available:
https://facebook.github.io/react/blog/2015/05/01/GraphQLintroduction.html.
[10]
F. Employee, “GraphQL,” Facebook, [Online]. Available:
https://facebook.github.io/GraphQL/.
[11]
V. Bojinov, RESTful Web
API Design with Node.js,
Birmingham B3 2PB: Packt Publishing Ltd, 2015.
[12]
A. Hanjura, Heroku Cloud Application Development,
Birmingham: Packt Publishing, 2014.
[13]
“Introducing
JSON,”
[Online].
Available:
http://www.json.org/.
[14]
H. Divayana, Konsep OOAD, Jakarta: STMIK Eresha, 2010.
[15]
J. Hermawan, Analisa Desain & Pemrograman Berorientasi
Objek dengan UML dan Visual Basic.NET, Yogyakarta: Andi, 2010.
[16]
K. Hamilton dan R. Miles, Learning UML 2.0, United States
of America: O'Reilly, 2006.
[17]
R. Osherove, The Art of Unit Testing Second Edition, Shelter
Island: Manning Publications Co, 2014.
[18]
F. Doglio, Pro REST API Development with Node.js, La Paz,
Canelones: Apress, 2015.
[19]
I. P. A. E. Pratama, E-commerce, E-Business, Mobile
Commerce, Bandung: BI-Obses, 2015.
[20]
Susila dan S. Vadivel, “QoS Measurement Tool for Web
Service Selection,” International Journal of Web Engineering, vol. 3,
no. 1, pp. 1-8, 2014.
95
BAB 1
PENDAHULUAN
1.1 Latar Belakang Masalah
Aplikasi Web saat ini berkembang pesat mulai dari front-end hingga backend, dan teknologi Web
ini mendukung perkembangan teknologi komputasi
terdistribusi (distributed computing) dimana teknologi ini memungkinkan
melakukan proses di banyak mesin, dan hasilnya dimanfaatkan oleh banyak mesin.
Salah satu dukungan teknologi Web pada komputasi terdistribusi adalah pada
pembangunan Web Service yang berfungsi sebagai aplikasi transaksi data antar
mesin yang terlibat di dalamnya. Konsep Web Service muncul untuk menjembatani
sistem-sistem informasi yang ada tanpa mempermasalahkan perbedaan platform
yang digunakan oleh masing-masing sumber [1]. Dalam pembangunan Web
Service ada beberapa teknologi yang dapat digunakan di antaranya SOAP, RESTful,
dan RPC-XML. Selain teknologi tersebut terdapat satu teknologi Web Service yakni
GraphQL, yang diciptakan dan digunakan oleh perusahaan Facebook ini mengubah
paradigma membaca dan menulis data berorientasi fungsi menjadi berorientasi
objek. Beberapa contoh objek dari facebook di antaranya adalah users, photos,
albums, dan koneksi/friendlist. Pendekatan ini membuat Facebook api lebih
sederhana dan konsisten saat bekerja dengan objek [2].
RESTful merupakan salah satu dari arsitektur-style Web Service yang
tergolong teknologi lama dan mudah untuk dipahami saat membangunnya. Namun
pada tahun 2015 teknologi baru yang diciptakan oleh perusahaan ternama yang
membidangi social media Facebook yakni GraphQL. Teknologi GraphQL ini
merupakan teknologi open source sehingga pengembang yang lain dapat ikut
mengembangkan teknologi ini. Saat ini satu-satunya kasus penggunaan produksi
GraphQL adalah Facebook. GraphQL berfungsi dengan baik untuk jejaring sosial
Facebook tetapi masih belum bisa dipastikan akan berfungsi baik pada sistem yang
lain seperti pada sistem Facebook [3]. Perusahaan Facebook kini secara perlahan
mengganti RESTful dengan GraphQL, walaupun tidak pada semua sistem dari
jejaring sosial Facebook itu sendiri. Permasalahan yang muncul yaitu perusahaan
1
2
Facebook memindahkan beberapa api dari RESTful api ke graph api. Facebook
memindahkan beberapa api ke graph api bukan tanpa alasan. Selain itu ada
beberapa penulis di situs medium.com menyatakan bahwa RESTful sudah layak
untuk digantikan oleh GraphQL dengan beberapa alasan, namun dari alasan yang
mereka tulis pada situs tersebut belum ditemukan artikel yang membahas mengenai
QoS(Quality of Service) Web Service pada GraphQL. Menurut hipotesa sementara
ada beberapa kekurangan pada teknologi RESTful, dan kekurangan tersebut dapat
diselesaikan menggunakan teknologi GraphQL api. Namun teknologi GraphQL ini
tergolong teknologi yang masih baru, belum ada pengujian secara khusus terhadap
teknologi ini.
Berdasarkan pemaparan permasalahan tersebut, didapatkan solusi yaitu
dengan membangun sebuah Web Service GraphQL untuk melakukan pengujian
performansi dan membandingkannya dengan Web Service yang menggunakan
RESTful. Salah satu objek yang dapat dijadikan sebagai sampel pengujian adalah
Web Service untuk m-commerce, karena perkembangan pada m-commerce sangat
cepat, dapat dilihat hadirnya beberapa m-commerce di Indonesia seperti lazada,
blibli, zalora, zoya, berrybenka, shopee, bhinneka.com, matahari mall, dan
bukalapak, sehingga hasil dari penelitian ini akan sangat berguna untuk beberapa
developer dalam mempertimbangkan migrasi Web Service api dari teknologi
sebelumnya ke teknologi GraphQL. Selain itu aspek yang dapat dijadikan sebagai
parameter ukur untuk perbandingan antara GraphQL dengan RESTful yakni QoS
Web Service.
1.2 Rumusan Masalah
Berdasarkan latar belakang, hal yang menjadi permasalahan adalah
hadirnya teknologi GraphQL yang tergolong baru ini belum ditemukan jurnal atau
paper yang menguji secara khusus seperti QoS, terutama pada domain m-commerce.
3
1.3 Maksud dan Tujuan
Maksud dari penelitian ini adalah menguji performansi dari teknologi
GraphQL pada domain selain sosial media yakni m-commerce. Adapun tujuan dari
penelitian ini adalah untuk melihat kualitas performance dari teknologi GraphQL,
sehingga dapat membantu developer Web Service api dalam mempertimbangkan
migrasi dari teknologi REST ke GraphQL. Dan membandingkannya menggunakan
aspek QoS Web Service sebagai parameter ukur.
1.4 Batasan Masalah
Adapun batasan masalah yang digunakan dalam penelitian ini adalah
sebagai berikut:
1. Dalam penelitian ini pembentukan query atau request data hanya yang berkaitan
dengan data produk.
2. Dalam penelitian ini melibatkan mobile device sebagai salah satu alat untuk
menguji request dan response dari server, mobile device menggunakan sistem
operasi android 4.4.4.
3. Untuk representasi data yang akan dijadikan sebagai pesan antara client-server
menggunakan format JSON.
4. Acuan pembanding antara RESTful dengan GraphQL menggunakan
karakteristik QoS yang sering digunakan [4] yakni Service time, reliability,
execution price, availability, performance , dan security, namun pada penelitian
ini security dan execution price tidak digunakan.
1.5 Metodologi Penelitian
Metodologi yang digunakan dalam penelitian ini adalah metode penelitian
komparatif yang bertujuan membandingkan antara dua objek atau lebih pada suatu
variabel tertentu. Objek yang dibandingkan dalam penelitian ini adalah GraphQL
dan RESTful dengan memperhatikan beberapa hal dari QoS Web Service. Adapun
tahapan-tahapan dalam penelitian ini sebagai berikut:
4
Analisis Domain
Analisis Fitur
Analisis Data
Analisis Query
Analisis GraphQL
API
Analisis RESTful
API
Pengujian
Gambar 1-1 Alur Penelitian
Berikut penjelasan dari setiap tahapan dalam penelitian.
1. Analisis Domain
Pada subbab ini akan dibahas mengenai beberapa hal mengenai masalah
yang terjadi pada domain kasus m-commerce, mulai dari permasalahan dari segi
mobile hingga commercenya itu sendiri.
2. Analisis Fitur
Pada subbab ini akan dijelaskan beberapa fitur yang terdapat di dalam
aplikasi m-commerce, tidak hanya fitur yang dianalisis namun data yang digunakan
pada setiap fiturpun akan dibahas. Analisis fitur ini bermaksud untuk mencari data
apa saja yang sering digunakan pada aplikasi m-commerce, setelah didapat data
yang sering digunakan, maka data tersebut akan digunakan sebagai objek . . .
3. Analisis Data
Berdasarkan hasil analisis fitur terdapat data yang sering diakses dalam mcommerce, data tersebut akan dianalisis mulai dari bentuk
4. Analisis Query
5
Pada subbab ini akan dilakukan analisis yang hampir sama dengan analisis
fitur namun perbedaannya terletak pada hasil dari analisis, target dari analisis ini
adalah dapat melihat bentuk query atau request data yang ada di dalam setiap fitur,
query yang terbentuk akan dijadikan sebagai bahan uji pada bab pengujian.
5. Analisis GraphQL API
Pada subbab ini akan dijelaskan mengenai cara kerja dari GraphQL API
menggunakan sample.
6. Analisis RESTful API
Pada tahap ini akan dilakukan analisis cara kerja dari teknologi RESTful API
dengan menggunakan sample.
7. Pengujian
Pengujian merupakan poin utama di mana penelitian mengenai analisis
performansi GraphQL dapat terlihat jelas, pada subbab ini akan dibahas mengenai
langkah-langkah pengujian Web Service api GraphQL dan RESTful. Setiap poin
dari QoS Web Service memiliki cara untuk menguji yang berbeda-beda, pada
subbab ini akan dibahas bagaimana cara pengujian pada setiap poin pada QoS Web
Service.
1.6 Sistematika Penulisan
Sistematika penulisan tugas akhir ini disusun untuk memberikan gambaran
umum mengenai penelitian yang dikerjakan. Sistematika penulisan dalam
dokumentasi skripsi ini adalah sebagai berikut:
BAB 1 PENDAHULUAN
Bab 1 akan membahas tentang latar belakang permasalahan, merumuskan
inti permasalahan yang dihadapi, mencari solusi atas masalah tersebut,
mengidentifikasi masalah tersebut, menentukan maksud dan tujuan, kegunaan
penelitian, pembatasan masalah, metode penelitian, dan sistematika penulisan.
6
BAB 2 LANDASAN TEORI
Bab 2 menguraikan bahan-bahan kajian, konsep dasar, dan teori dari para
ahli yang berkaitan dengan penelitian. Meninjau permasalahan dan hal-hal yang
berguna dari penelitian-penelitian dan sintesis serupa yang pernah dikerjakan
sebelumnya dan menggunakannya sebagai acuan pemecahan masalah pada
penelitian ini.
BAB 3 ANALISIS
Bab 3 menguraikan hasil analisis dari objek penelitian untuk mengetahui hal
atau masalah apa yang timbul dan mencoba memecahkan masalah tersebut dengan
mengaplikasikan perangkat-perangkat dan pemodelan yang digunakan.
BAB 4 PENGUJIAN SISTEM
Bab 4 menguraikan tentang perancangan solusi beserta implementasinya
dari masalah-masalah yang telah dianalisis. Pada bagian ini juga akan ditentukan
bagaimana sistem dirancang, dibangun, diuji dan disesuaikan dengan hasil
penelitian.
BAB 5 KESIMPULAN DAN SARAN
Bab 5 berisi kesimpulan dan saran yang merupakan jawaban yang melatar
belakangi masalah pada Bab 1, dan saran untuk perbaikan dan menindaklanjuti hasil
penelitian yang nantinya akan berguna bagi pengembang perangkat lunak ini ke
depannya.
BAB 2
LANDASAN TEORI
2.1 Web Service
Web Service merupakan salah satu komponen sistem terdistribusi pada SOA
(Service Oriented Architecture). Service dibangun untuk menyediakan interface
yang memproses dan mengirim pesan dalam bentuk xml atau json. Service
menggunakan object oriented untuk mendefinisikan pesan yang akan dikirim
kepada client atau Service yang lain. Selain menyediakan interface untuk menerima
dan mengirim pesan dari client atau Service lain melalui protokol (HTTP, SMTP,
TCP), Service juga menangani beberapa business logic dan beberapa operasi CRUD
di dalamnya.
2.2 Quality of Service for Web Service
Untuk membangun sebuah sistem informasi yang berukuran kecil hingga
besar diperlukan sebuah standarisasi dan mekanisme, sehingga sistem yang
dibangun memiliki kualitas yang baik, selain itu mudah untuk maintenance. Untuk
membangun sebuah sistem informasi Web Service ada beberapa standar yang harus
diperhatikan di antaranya. [5]
1. Performance
Performance merupakan salah satu hal yang sangat penting dalam dunia
teknologi karena tujuan dibangunnya sebuah teknologi diharapkan dapat membantu
pekerjaan manusia, namun tidak hanya sekedar membantu tapi mempercepat
pekerjaan, sebagai contoh dalam hal menghitung, kalkulator dapat membantu
pekerjaan menghitung dalam waktu yang jauh lebih cepat. Oleh karena itu dalam
pembangunan sistem, performance perlu perhatian khusus, mulai dari algoritma
yang digunakan, stack, hingga hardware yang akan menjalankan sistem yang
dibangun.
7
8
Pengukuran performance
pada QoS Web
Service lebih fokus pada
pengukuran throughput, response time, dan latency [6] [7] [8].
Throughput
merepresentasikan permintaan/satuan waktu, dimana throughput ini mengukur
seberapa banyak request yang ditangani atau di-handle oleh server secara periodik.
Response time mengukur berapa lama server mengirimkan data kepada client.
Latency mengukur waktu delay antara waktu client melakukan request dan waktu
ketika client mendapatkan response dari server.
Gambar 2-1 Client Server Transaction
1. Throughput
Pengukuran throughput dapat dilakukan dengan cara melakukan lebih dari
satu request dalam kurun waktu tertentu dan dalam dilakukan secara bersamaan.
Untuk mendapatkan nilai maksimal throughput dapat menggunakan rumus sebagai
berikut:
Maksimal throughput =
�ℎ
�
�
�
� ��
� ��
... persamaan(2.1)
Proses pengukuran nilai maksimal throughput dapat dilakukan dengan
melakukan logging atau pencatatan jumlah request yang di-handle oleh server
dalam kurun waktu tertentu.
9
2. Latency
Pengukuran waktu latency merupakan waktu delay dimana client menunggu
response yang diberikan oleh server. Untuk mendapatkan nilai waktu delay dapat
menggunakan rumus sebagai berikut:
Latency = response time – request time ................................ persamaan(2.2)
Pengukuran latency dapat dilakukan dengan cara melakukakan logging atau
pencatatan pada client, yang dapat dicatat adalah waktu ketika client melakukan
request ke server dan waktu ketika client mendapatkan response dari sever. Setelah
waktu tersebut didapatkan, maka rumus diatas dapat digunakan untuk mendapatkan
nilai latency.
3. Response Time
Pada pengukuran ini merupakan perhitungan waktu yang diperlukan untuk
menyelesaikan request. Waktu yang dihitung adalah waktu dimana server
melakukan execution time dan memberikan response kepada client. Untuk
mendapatkan nilai response time dapat menggunakan rumus sebagai berikut:
Response time = execution time + data transferred time ......... persamaan(2.3)
Data transfer time merupakan waktu dimana server mengirimkan data json
ke client. Pengukuran ini juga dapat menggunakan logging atau pencatatan, waktu
yang dicatat adalah waktu yang diperlukan untuk business logic yang didapat dari
waktu ketika server mendapatkan request hingga business logic selesai dilakukan,
dan waktu yang diperlukan untuk mengirim data ke client yang didapat dari waktu
business logic selesai dilakukan hingga data tersebut sampai di client.
Parameter qualitas performance pada Web Service dapat dilihat dari empat
point yang telah dijabarkan sebelumnya yakni throughput, response time, latency
10
dan execution time. Web Service yang memiliki performance yang baik dapat
diliha dari throughput yang cepat, latency yang rendah, response yang cepat, dan
execution cepat.
2. Reliability
Reliability merupakan tolak ukur untuk tingkat maintain Web Service.
Mengukur tingkat kegagalan pada sistem setiap hari, minggu, bulan, atau tahun
tergantung dari seberapa besar kemampuan pengembang untuk melakukan
maintain. Karena tidak ada jaminan semua pesan atau response akan sampai ke
tujuan.
3. Scalability
Dalam pembangunan sebuah sistem akan dimulai dari prototype di mana
sistem belum siap untuk digunakan secara utuh, karena beberapa fungsi masih
memiliki error atau bug. Setelah semuanya fungsional dapat dijalankan sesuai
dengan harapan developer tidak akan berhenti untuk mengembangkan lagi sistem
yang telah dibangun, oleh karena itu sistem sangat dituntut untuk dapat
dikembangkan menjadi sistem yang sesuai dengan kebutuhan saat itu. Misalnya
dalam meningkatkan kemampuan sistem dalam memproses setiap request dari user
yang semakin meningkat jumlahnya.
4. Capacity
Web Service saat ini salah satu distributed system yang sering digunakan
untuk transaksi data, client atau system yang menggunakan layanan dari Web
Service tersebut bermacam-macam dari Web , desktop application, hingga mobile.
Pada kasus m-commerce saat ini sudah banyak aplikasi yang menyediakan layanan
untuk membeli barang secara online atau pengguna dapat menjadi penjual untuk
pengguna lainnya. Pengguna pada aplikasi lazada telah mencapai lebih dari sepuluh
juta download, dengan demikian Web Service lazada harus mampu untuk menghandle request dari pengguna yang begitu banyak dalam waktu yang bersamaan.
5. Robustness
11
Request client yang memiliki parameter untuk diproses di dalam server
yang terkadang ada beberapa parameter tidak memiliki nilai yang berakibat
kesalahan pada sistem yang dikarenakan human error dari pengguna atau validasi
pada sistem masih kurang dan sistem Web Service dituntut untuk dapat menangani
masalah tersebut.
6. Exception Handling
Dalam pembangunan sistem memungkinkan beberapa hal yang tidak
terprediksi dapat terjadi. Contoh sederhana dalam hal request, client akan
melakukan request ke server dengan beberapa parameter, namun tidak semua
parameter bersifat required, maka server harus mampu untuk menanggulangi jika
ada parameter yang tidak bersifat required tidak memiliki nilai.
7. Accuracy
Akurasi merupakan hal penting dalam sistem informasi, namun di sini
maksud dari akurasi adalah tingkat kesalahan yang dihasilkan oleh layanan Web .
8. Integrity
Integrity salah satu hal yang wajib ada di dalam Web
Service untuk
mencegah unauthorized access atau modifikasi pada sistem atau data. Ada dua tipe
integrity yakni data integrity dan transactional integrity. Data integrity memastikan
apakah data yang di transfer telah dimodifikasi ketika transit. Sedangkan
transactional integrity mengacu pada prosedur yang menjamin menjaga database
integrity dalam transaksi.
9. Accessibility
Client dari Web Service tidak hanya satu jenis, ada beberapa jenis client
yakni mobile, desktop, maupun Service lainnya. Jadi Web Service harus mampu
untuk melayani setiap request yang berbeda-beda.
10. Availability
12
Pembangunan Web Service api tidak semata-mata dibangun dari awal
sebuah startup atau perusahaan dari awal, terkadang pembangunan Web Service
dibangun di tengah jalan dengan alasan permintaan dari pengguna atau ekspansi
dari perusahaan itu sendiri ataupun rencana untuk membangun sistem terintegrasi.
Maka dari itu Web Service harus mampu tersedia sesegera mungkin untuk berbagai
keperluan dalam integrase ataupun ekspansi.
11. Interoperability
Dalam pembangunan sebuah sistem informasi khususnya Web Service tidak
hanya memikirkan masalah bahasa pemrograman yang digunakan namun ada
beberapa hal seperti sistem dari database. Tidak hanya itu developer juga harus
memikirkan bagaimana untuk menggunakan sistem dari database di dalam Web
Service yang dibangun. Selain database ada juga sistem lain yakni jalur komunikasi
seperti http protocol. Jadi Web
Service harus memiliki kemampuan untuk
berinteraksi dengan sistem lain tanpa akses yang rumit.
12. Security
Salah satu media sosial dunia yakni facebook memiliki jutaan data pribadi
mengenai penggunanya di seluruh dunia. Data tersebut bersifat rahasia, tidak
sembarang orang atau kelompok dapat mengakses data tersebut. Sehingga
perusahaan facebook harus mampu untuk menjaga semua data dari setiap
penggunanya. Kini facebook telah menyediakan Service untuk perusahaan atau
aplikasi lain agar dapat mengakses akun tertentu dengan beberapa kebijakan dari
facebook untuk menjaga data pengguna agar tidak semua data dapat diambil begitu
saja. Maka dari itu Web Service yang dibangun harus memiliki sistem keamanan
seperti authentication, authorization, confidentiality, traceability and auditability,
data encryption, non-repudation.
2.3 GraphQL
GraphQL maupun REST tidak terpaku pada database yang digunakan, pada
dasarnya Web Service mengambil sejumlah data dari database yang nantinya akan
13
di proyeksikan ke dalam bentuk API. Prinsip-prinsip yang digunakan GraphQL
untuk membuat suatu interface atau API sebagai berikut: [9]
1. Hierarchical
GraphQL menggunakan hierarki untuk relasi antar objek, seperti halnya
dalam REST menggunakan join statement pada SQL.
2. Client Specified Queries
Pada GraphQL setiap client request untuk data fetching atau data
manupulate
menggunakan query yang di dalamnya berisi model data yang
dibutuhkan, berbeda dengan REST, semuanya ketentuan data yang akan disajikan
dalam API sudah ditentukan, karena konsep everything is resource pada REST.
3. Backward Compabilities
Setiap mobile application minimal dalam tiga bulan akan diperbaharui, pada
kasus ini setiap melakukan request data ada kemungkinan berbeda-beda setiap
client, karena tidak semua client akan memperbaharui aplikasinya. sehingga
GraphQL dari itu setiap melakukan requent data ke GraphQL menggunakan
specified query bukan resource.
4. Strongly Typed
Ketika client mengirim request dengan query, setiap item yang ada di dalam
objek query akan di cek satu per satu apakah data yang di-request tersedia atau
tidak, jika tidak tersedia maka GraphQL akan membuat pesan error sebelum query
di eksekusi.
GraphQL dibangun dalam waktu yang cukup lama, karena pembangunan
GraphQL ini diharapkan dapat menyelesaikan beberapa permasalahan pada kasus
tertentu. [10]
1. Operation
14
Teknologi GraphQL memiliki dua buah operasi yang akan digunakan
sebagai alat untuk transaksi data client-server yakni query dan mutation, query
hanya digunakan untuk fetching data sedangkan mutation digunakan untuk
modifikasi data.
2. Selection Set
Selection set merupakan sebuah set informasi yang dibutuhkan oleh client,
dalam selection set dapat berisi Field, FragmentSpread, atau InlineFragment. Dan
client akan mendapatkan data yang sama persis dengan selection set yang dikirim
ke server. Berikut contoh bentuk dari selection set.
{
id
nama
epan
namaBelakang
}
Gambar 2-2 Selection Set
3. Field
Sebuah selection set terbentuk dari satu atau beberapa field. Sebuah field
menjelaskan satu informasi. Kumpulan field dalam satu selection set menjelaskan
data yang kompleks atau keterhubungan dengan data yang lain. Untuk mendapatkan
data yang lebih kompleks dalam data, memungkinkan dalam sebuah field berisi
selection set. Semua operasi pada GraphQL harus menentukan selections pada field
yang mengembalikan nilai scalar untuk memastikan response yang didapat jelas.
15
{
me {
id
firstName
lastName
birthday {
month
day
}
friends {
name
}
}
}
Gambar 2-3 Field
Field di level pertama pada selection set menandakan informasi yang dapat
diakses secara global dari client dan informasi tersebut merupakan informasi client
utama atau current viewer.
4. Arguments
Secara konsep field merupakan sebuah functions yang mengembalikan nilai,
dan dalam beberapa kasus field menerima argument yang dapat mengubah nilai dari
hasil request. Sebagai contoh client akan me-request data user dengan id 4 dengan
spesifikasi profile picture dengan ukuran 100 x 100,
{
user(id: 4) {
id
nama
profilePic(size: 100)
}
}
Gambar 2-4 Arguments
5. Field Alias
16
Secara default objek dari response akan menggunakan nama field. Namun
nama field yang digunakan juga diganti dengan nama alias sesuai dengan
kebutuhan, nama alias digunakan untuk mempermudah dalam pembacaan data
response dan menghindari duplikat key. Berikut contoh dari penggunaan alias.
{
user(id: 4) {
id
name
smallPic: profilePic(size: 64)
bigPic: profilePic(size: 1024)
}
}
Gambar 2-5 Field Alias
Dari objek request tersebut maka response dari server akan berbentuk
seperti berikut.
{
"user": {
"id": 4,
"name": "Mark Zuckerberg",
"smallPic": "https://cdn.site.io/pic-4-64.jpg",
"bigPic": "https://cdn.site.io/pic-4-1024.jpg"
}
}
Gambar 2-6 Result Field Alias
6. Fragments
Fragment merupakan unit utama dalam komposisi GraphQL. Fragment
memungkinkan untuk menggunakan selections berulang kali pada sebuah field.
Inline fragment dapat digunakan di dalam selection . . . . . .
17
query noFragments {
user(id: 4) {
friends(first: 10) {
id
name
profilePic(size: 50)
}
mutualFriends(first: 10) {
id
name
profilePic(size: 50)
}
}
}
Gambar 2-7 Without Fragment
Selection set friends dan mutualFriend memiliki field yang sama, maka
selection set ini dapat dimasukkan ke dalam sebuah fragment.
query withFragments {
user(id: 4) {
friends(first: 10) {
. . .friendFields
}
mutualFriends(first: 10) {
. . .friendFields
}
}
}
fragment friendFields on User {
id
name
profilePic(size: 50)
}
Gambar 2-8 With Fragment
Memakai fragment menggunakan operator ( . . . ). Semua field yang berada
di dalam fragment akan dimasukkan ke dalam field query yang menggunakan
fragment. Fragment juga dapat diaplikasikan pada multiple levels fragment, berikut
contoh dari multiple level.
18
query withNestedFragments {
user(id: 4) {
friends(first: 10) {
. . .friendFields
}
mutualFriends(first: 10) {
. . .friendFields
}
}
}
fragment friendFields on User {
id
name
. . .standardProfilePic
}
fragment standardProfilePic on User {
profilePic(size: 50)
}
Gambar 2-9 Profile Picture Fragment
2.4 REST
REST mendefinisikan satu set prinsip arsitektur di mana dapat digunakan
untuk mendisain Web Service yang berfokus pada resource sistem, termasuk
bagaimana resource memiliki alamat (URL address) dan dapat dikirim kepada
client yang memiliki bahasa yang berbeda-beda. Interaksi antara client dengan
server menggunakan interface yang bisa diakses oleh protokol http yang sering
disebut sebagai API (Application Programming Interface). Dikarenakan
pembangunan Service untuk interaksi atau manipulasi data menggunakan bahasa
native dari SQL database yaitu insert, select, update, delete, maka verb yang
digunakan ada empat di antaranya post, get, put, dan delete. Dalam pembangunan
RESTful Web Service api's ada beberapa prinsip yang digunakan, di antaranya: [11]
1. Each resource is identifiable by a unique
Jumlah resource pada suatu sistem lebih dari satu, dan untuk mengakses
resource tersebut diperlukan URI, namun URI harus bersifat unik sama halnya
19
dengan nomor ktp, satu sama lain harus berbeda untuk mengidentifikasi pemilik
dari nomor ktp tersebut.
2. User the standard HTTP methods
Http protocol memiliki delapan verb yaitu sebagai berikut:
1. GET
2. POST
3. PUT
4. DELETE
5. HEAD
6. OPTIONS
7. TRACE
8. CONNECT
Pada teknologi RESTful ini tidak semua verb HTTP digunakan, hanya empat
yang digunakan di antaranya
Tabel 2-1 Verb RESTful
HTTP Verb
GET
Action
Kode status respon
Request terhadap
“200 OK”, jika resource tersedia, “404 Not
resource yang sudah ada
Found”, jika resource tidak tersedia, dan “500
Intenal Server Error”, jika terdapat kesalahan di
dalam server.
PUT
Memasukan data
memperbaharui data
atau
“201 CREATED”, jika data telah masuk ke dalam
database, “200 OK”, jika data telah diperbaharui,
“500 Intenal Server Error”, jika terdapat kesalahan
di dalam server.
POST
Memperbaharui data
“200 OK”, jika data telah diperbaharui, “500
Intenal Server Error”, jika terdapat kesalahan di
dalam server.
DELETE
Menghapus data
“200 OK”, jika resource terhapus, “404 Not
Found”, jika resource yang akan dihapus tidak
tersedia, dan “500 Intenal Server Error”, jika
terdapat kesalahan di dalam server.
20
3. Resource can have multiple representations
REST dapat mendukung beberapa format data representasi tergantung pada
request yang dilakukan, selama server mendukung format tersebut.
2.5 Android
Android merupakan sebuah sistem operasi yang berjalan dia atas linux
karnel, sistem operasi ini diterapkan pada mobile device seperti smartphone,
komputer tablet, dan smartwatch, tidak hanya mobile device android telah
digunakan pada kendaraan roda empat dan television. Android pertama kali
dikembangkan oleh Android Inc., dan pada tahun 2005 Google membeli dan
mengembangkannya hingga saat ini.
Android memiliki paradigma pemrograman yang berbeda dengan
pemrograman pada umumnya dimana dalam pemrograman java, method yang
pertama kali dijalankan adalah main(), sedangkan pada android menjalankan kode
dalam method Activity dengan menerapkan callback tertentu yang sesuai dengan
tahap tertentu dari siklus hidup. siklus hidup berguna untuk memastikan aplikasi
tidak
menghabiskan
sumber
daya
baterai.
Gambar 2-10 Android Lifecycle
Terdapat beberapa state dalam siklus hidup android yang terjadi seperti
diilustrasikan pada Gambar 2-10 Android Lifecycle
21
1. Created
Sebuah aplikasi pertama kali dijalankan dan mengeksekusi method onCreate()
termasuk menginisialisasi komponen tampilan.
2. Started
State ini secara langsung akan diakses setelah onCreate() dijalankan, dan ketika
aplikasi dijalankan setelah aplikasi tersebut di tutup.
3. Resumed
State resumed akan dijalankan setelah state paused. state ini akan menjalankan
perintah yang ada di dalam method onResume()..
4. Paused
Pada state ini semua aktivitas dalam aplikasi akan dihentikan sementara. state
ini berjalan ketika ada aplikasi yang berjalan dengan prioritas lebih tinggi.
aplikasi tidak bisa menerima input dari user dan tidak bisa mengeksekusi
perintah kode program.
5. Stopped
Pada state ini aplikasi dalam keadaan mati, tetapi background Service tetap
berjalan.
6. Destroyed
Aplikasi benar - benar mati, tidak ada proses apapun yang berjalan termasuk
background Service.
2.6 BlazeMeter
Pengujian performance menggunakan acuan QoS Web Service dapat
dilakukan dengan menggunakan salah satu tool BlazeMeter. Tool BlazeMeter
berbasis cloud untuk mempermudah pengujian. BlazeMeter memiliki fitur yang
dibutuhkan untuk menguji performance
di antaranya fitur response time,
thoughput, dan delay. Dalam menguji performance BlazeMeter mengeksekusi
client dan server pada cloud, sehingga ketika melakukan pengujian BlazeMeter
dapat ditutup atau melakukan pengujian yang lainya. Selain itu BlazeMeter juga
dapat dikonfigurasi sesuai dengan kebutuhan mulai dari jumlah user virtual yang
22
akan digunakan untuk mengakses Service api, jumlah iteration untuk request, waktu
yang digunakan untuk menguji Web Service api, dan jumlah waktu delay antar
requet untuk satu user virtual. Hasil pengujian disajikan dengan grafik dan data
numerik untuk setiap mengujian secara detail.
2.7 Heroku cloud
Heroku merupakan salah satu penyedia platform-as-a-Service (PaaS)
terkemuka di bisnis cloud software, yang membuktikan dirinya sebagai solusi PaaS
terkemuka untuk perusahaan kecil dan besar. Dengan peningkatan yang konsisten
dan filosofinya kenyamanan melebihi konfigurasi, menjadikan developer untuk
fokus dalam menulis aplikasi Web . Hal yang bersangkutan dengan server, building,
deploying, running, dan scaling aplikasi akan diatasi oleh Heroku.
Heroku menyediakan dukungan platform untuk Ruby, Ruby on Rails, Java,
Node.js, Clojure, Scala, Python, dan PHP. Arsitektur Heroku add-on
memungkinkan developer menyesuaikan penggunaan berbagai paket pihak ketiga
berdasarkan kebutuhan. Developer memiliki fleksibilitas untuk memilih plan basic
atau premium berdasarkan kebutuhan Web site. Developer juga bisa mempercepat
aplikasi dengan menambahkan resources seperti memcached untuk caching data,
sehingga menciptakan aplikasi yang powerful yang kaya dengan fitur [12].
2.8 JSON
Interaksi antara client dengan server mempunyai banyak cara, salah satu
cara yang cukup familiar adalah interaksi yang menggunakan interface antara satu
sistem dengan sistem lainnya yang memiliki platform yang berbeda ataupun sama,
atau sering disebut sebagai API(Application Promgramming Interface). Sebuah
interaksi memiliki min satu pesan didalamnya, format pesan yang sering digunakan
dalam interaksai client-server adalah xml dan json. Json merupakan salah satu
format tulisan yang ringan, mudah dibaca oleh manusia ataupun mesin, dan mudah
bagi mesin untuk men-genterate atau untuk memecahkan atau mengubah menjadi
bentuk lain sesuai dengan kebutuhan dari satu pesan json. [13]
23
2.9 M-Commerce
Perkembangan dalam bidang penjualan semakin meningkat sejak hadirnya
penjualan online atau dapat disebut sebagai e-commerce. Banyak kalangan
memulai usaha dengan mengandalalkan e-commerce, karena tidak perlu membeli
atau menyewa bangunan untuk sebuah toko, cukup dengan membuat sistem
penjualan online atau e-commerce penjual cukup diam di rumah dan sediakan satu
ruangan sebagai gudang. E-comnmerce memiliki beberapa jenis berdasarkan peran
di dalamnya, yaitu B2B (Business to Business), B2C (Business to Client), C2C
(Clinet to Client).
2.10
Object Oriented Analysis And Design
Analisis dan desain berorientasi objek adalah cara baru dalam memikirkan
satu masalah dengan menggunakan model yang dibuat menurut konsep sekitar
dunia nyata. Tujuan dari analisis berorientasi objek adalah untuk mengembangkan
model yang menggambarkan perangkat lunak komputer karena bekerja untuk
memenuhi seperangkat persyaratan yang ditentukan usir [14]. Tools yang dapat
digunakan pada pendekatan analisis pengembangan sistem secara objek yaitu
menggunakan UML.
Unified Modelling Language (UML) adalah sebuah bahasa yang telah
menjadi
standar
dalam
industri
untuk
visualisasi,
merancang
dan
mendokumentasikan sistem piranti lunak. UML menggunakan class dan operation
object dalam konsep dasarnya, maka ia lebih cocok untuk penulisan piranti lunak
dalam bahasa bahasa berorientasi objek [15]. Dalam membangun block UML ada
tiga hal yang harus diperhatikan, yaitu object (memodelkan konsep), relationship
(menghubungkan object), dan diagram (grouping yang saling menghubungkan
antara object dan relationship. Diagram yang umum dipakai dalam analisis dan
desain adalah:
1. Use Case Diagram
Use Case Diagram menggambarkan fungsionalitas yang diharapkan dari
sebuah sistem. Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan
“bagaimana”. Sebuah Use case merepresentasikan sebuah interaksi antara aktor
24
dengan sistem. Sebuah use case dapat meng-include fungsionalitas use case lain
sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan bahwa use
case yang di-include akan dipanggil setiap kali use case yang meng-include
dieksekusi secara normal. Sebuah use case dapat di-include oleh lebih dari satu use
case lain, sehingga duplikasi fungsionalitas dapat dihindari dengan cara menarik
keluar fungsionalitas yang serupa. Sebuah use case juga dapat meng-extend usecase
lain dengan behaviour-nya sendiri. Sementara hubungan generalisasi antar use case
menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain.
Dasar menentukan sebuah use case adalah use case merupakan sesuatu yang
menyediakan beberapa hasil terukur kepada pengguna atau sistem eksternal. Use
case harus memiliki sangat jelas kriteria lulus / gagal. Pengembang, tester, penulis
teknis, dan pengguna harus secara eksplisit tahu apakah sistem memenuhi kasus
penggunaan atau tidak. Setiap bagian dari use case yang memenuhi tes sederhana
ini mungkin menjadi kandidat yang baik untuk use Chase. Dasar pembangunan use
case diagram dapat dilihat pada Gambar 2-11 Dasar Pembangunan Use Case
Diagram.
Gambar 2-11 Dasar Pembangunan Use Case Diagram
2. Use Case Scenario
Sebuah diagram yang menunjukkan use case dan aktor mungkin menjadi titik
awal yang bagus, tetapi tidak memberikan detail yang cukup untuk desainer sistem
untuk benar-benar memahami persis bagaimana sistem dapat terpenuhi. Cara
terbaik untuk mengungkapkan informasi penting ini adalah dalam bentuk
penggunaan use case scenario berbasis teks per use casenya. Berikut adalah dasar
25
format penulisan use case scenario [16]. Dasar pembangunan use case scenario
dapat dilihat pada Error! Reference source not found..
Tabel 2-2 Dasar Pembangunan Use Case Scenario
Use Case Name
Goal In Context
Description
Related Use Case
Successful
End
Condition
Failed End Condition
Actors
Trigger
Main Flow
Extension
Berisi nama dari use case yang akan digunakan
Menjelaskan apa yang aktor coba untuk dapatkan
dari use case
Menjelaskan gambaran dari use case
Daftar use case yang berhubungan dengan use case
tersebut
Kondisi use case jika berhasil
Kondisi use case jika gagal
Daftar aktor yang dapat mengakses use case
Aktifitas yang dilakukan untuk mengawali use case
Step Action
1
Deskripsi urutan aksi dari aktifitas use case
2
Step Branching Action
2.1
Deskripsi urutan aksi lain selain urutan aksi
utama
3. Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam dan di
sekitar sistem berupa message yang digambarkan terhadap waktu. Sequence
diagram terdiri atar dimensi vertikal (waktu) dan dimensi horizontal (objek-objek
yang terkait). Sequence diagram biasa digunakan untuk menggambarkan skenario
atau rangkaian langkah-langkah yang dilakukan sebagai respons dari sebuah event
untuk menghasilkan output tertentu. Diawali dari apa yang men-trigger aktivitas
tersebut, proses dan perubahan apa saja yang terjadi secara internal dan output apa
yang dihasilkan.
Masing-masing objek, termasuk aktor, memiliki lifeline vertikal. Message
digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. Pada fase
desain berikutnya, message akan dipetakan menjadi operasi/metoda dari class.
Activation bar menunjukkan lamanya eksekusi sebuah proses, biasanya diawali
dengan diterimanya sebuah message [15]. Untuk objek-objek yang memiliki sifat
khusus, standar UML mendefinisikan icon khusus untuk objek boundary, controller
dan persistent entity. Dasar pembangunan sequence diagram dapat dilihat pada
Gambar 2-12 Dasar Pembangunan Sequence Diagram.
26
Gambar 2-12 Dasar Pembangunan Sequence Diagram
4. Class Diagram
Class adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan
sebuah objek dan merupakan inti dari pengembangan dan desain berorientasi objek.
Class
menggambarkan
keadaan
(atribut/properti)
satu
sistem,
sekaligus
menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). Class
diagram menggambarkan struktur dan deskripsi class, package dan objek beserta
hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lain-lain.
Class memiliki tiga area pokok:
a. Nama dan stereotype
b. Atribut
c. Metoda
Atribut dan metoda dapat memiliki salah satu sifat berikut:
a. Private, tidak dapat dipanggil dari luar class yang bersangkutan.
b. Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak
yang mewarisinya.
c. Public, dapat dipanggil oleh siapa saja.
Class dapat merupakan implementasi dari sebuah interface, yaitu class
abstrak yang hanya memiliki metoda. Interface tidak dapat langsung
diinstansiasikan, tetapi harus diimplementasikan dahulu menjadi sebuah class.
27
Sesuai dengan perkembangan class model, class dapat dikelompokkan menjadi
package. Kita juga dapat membuat diagram yang terdiri atas package.
Class memiliki tipe-tipe relationship, diantaranya:
a. Asosiasi, yaitu hubungan statis antar class. Umumnya menggambarkan class
yang memiliki atribut berupa class lain, atau class yang harus mengetahui
eksistensi class lain.
b. Agregasi, yaitu hubungan yang menyatakan bagian terdiri atas dimana ketika
satu class di share atau direferensikan kepada objek yang ada di class lain.
c. Pewarisan, yaitu hubungan hirarkis antar class. Class dapat diturunkan dari
class lain dan mewarisi semua atribut dan metoda class asalnya dan
menambahkan fungsionalitas baru, sehingga ia disebut anak dari class yang
diwarisinya. Kebalikan dari pewarisan adalah generalisasi.
d. Komposisi, yaitu jenis relasi class diagram yang kuat dimana jika sebuah class
tidak bisa berdiri sendiri dan harus merupakan bagian dari class yang lain,
maka class tersebut memiliki relasi Composition terhadap class tempat dia
bergantung tersebut. Sebuah relationship composition digambarkan sebagai
garis dengan ujung berbentuk jajaran genjang berisi/solid.
e. Depedensi, salah satu jenis relasi class diagram yang lemah dimana objek
dalam suatu class akan bekerja sangat singkat dengan objek yang ada pada class
lain.
Gambar 2-13 Dasar Pembangunan Class Diagram
5. Activity Diagram
28
Activity diagram menggambarkan berbagai alur aktivitas dalam sistem yang
sedang dirancang, bagaimana masing-masing aliran berawal, decision yang
mungkin terjad