2.1. Konsep Elasticsearch

BAB 2 LANDASAN TEORI

Landasan teori dan dasar pengetahuan berikut terdiri atas informasi yang dikumpulkan dari berbagai sumber untuk mendukung proses implementasi Elasticsearch search engine pada Sistem Manajemen Order.

2.1.

Konsep Elasticsearch

2.1.1

Search Engine Search engine adalah aplikasi praktis dari teknik pencarian informasi ke koleksi teks berskala besar. Search engine masuk dalam sejumlah konfigurasi yang mencerminkan aplikasi yang mereka rancang. Web search engines, seperti Google dan Yahoo!, harus dapat menangkap sejumlah terabyte data, dan kemudian memberikan waktu respons subsecond ke jutaan queri yang dikirimkan setiap hari dari seluruh dunia. Enterprise search engines, misalnya Autonomy8 harus dapat memproses beragam sumber informasi di perusahaan dan menggunakan pengetahuan khusus dari perusahaan sebagai bagian dari pencarian dan tugas terkait. Desktop search engines, seperti fitur pencarian Microsoft Vista ™, harus dapat dengan cepat memasukkan dokumen, halaman web, dan email baru saat orang tersebut membuat atau melihatnya. Open source search engines adalah kelas sistem penting lainnya yang memiliki tujuan desain yang agak berbeda daripada search engine komersial. Tiga sistem yang diminati adalah Lucene, Lemur, dan Galago. Lucene adalah search engine berbasis Java yang populer dan telah digunakan untuk berbagai aplikasi komersial. Teknik pengambilan informasi yang digunakannya relatif sederhana (Croft, Metzler, & Strohman, 2015).

2.1.2

Elasticsearch Menurut Gormley & Tong (2015), Elasticsearch adalah open-source search engine yang dibangun di atas Apache Lucene ™, perpustakaan mesin pencari full-text. Lucene bisa dibilang perpustakaan mesin pencari

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

mutakhir, berkinerja tinggi, dan berfitur lengkap yang ada sekarang-baik open source maupun hak milik. Bagaimanapun, elasticsearch jauh lebih baik daripada hanya Lucene dan lebih dari sekedar “hanya” pencarian full-text. Hal ini juga dapat digambarkan sebagai berikut: a. Toko dokumen real-time terdistribusi dimana setiap feld di indeks dan dicari b. Mesin pencari terdistribusi dengan analisis real-time c. Mampu melakukan penskalaan ke ratusan server dan petabyte yang terstruktur dan data tidak terstruktur Dan ini membungkus seluruh fungsionalitas yang ada menjadi suatu server mandiri yang yang dapat berbicara dengan aplikasi melalui RESTful API, menggunakan klien web dari bahasa pemrograman favorit Anda, atau bahkan dari command line. Elasticsearch dapat didownload, digunakan, dan dimodifikasi secara gratis dan tersedia di bawah lisensi Apache 2, salah satu lisensi open source paling fleksibel yang tersedia. Beberapa konsep yang hadir dengan Elasticsearch yang dapat membantu pemahaman sepenuhnya tentang bagaimana elasticsearch bekerja (Gupta, 2014) dapat dijelaskan sebagai beirkut: 1.

Index Elasticsearch menyimpan datanya dalam satu atau lebih indeks. Menggunakan kesamaan dari dunia SQL, pengindeksan mirip dengan sebuah basis data. Ini digunakan untuk menyimpan dokumen dan membacanya. Elasticsearch menggunakan perpustakaan Apache Lucene library untuk menulis dan membaca data dari indeks. Indeks elasticsearch mungkin dibangun lebih dari satu indeks Apache Lucene dengan menggunakan “Shards”.

2.

Dokumen Dokumen adalah entitas utama di dunia elasticsearch. Pada akhirnya, semua kasus penggunaan elasticsearch bisa dilakukan pada titik dimana itu semua tentang mencari dokumen dan menganalisisnya. Dokumen terdiri dari fields, dan masing-masing field diidentifikasi


dengan namanya dan bisa mengandung satu atau beberapa nilai. Setiap dokumen mungkin memiliki kumpulan field yang berbeda; tidak ada skema atau struktur yang dipaksakan. 3.

Tipe Setiap dokumen dalam Elasticsearch memiliki tipe yang didefinisikan. Ini memungkinkan kita untuk menyimpan berbagai jenis dokumen dalam satu indeks dan pemetaan yang berbeda untuk jenis dokumen yang berbeda.

4.

Mapping Semua dokumen dianalisis sebelum diindeks. Inputan teks dibagi menjadi token, token mana yang harus disaring keluar, atau proses tambahan apa, seperti menghapus tagar HTML, sangat dibutuhkan. Disinilah tahap pemetaan mulai dimainkan; dia memegang semua informasi tentang rantai analisis.

2.1.3

Denormalisasi pada Elasticsearch Menurut Gormley & Tong (2015), Suatu cara untuk meningkatkan performansi yang dilakukan pada Elasticsearch adalah dengan melakukan denormalisasi data dalam index. Dengan memiliki salinan data pada masing-masing dokumen, hal tersebut dapat mengurangi kebutuhan dilakukannya join antar index. Sebagai contoh, jika ingin dapat menemukan sebuah blogpost dari nama pengguna yang menulisnya, termasuk username dari pengguna blogpost:


Sekarang kita dapat menemukan blogpost yang berjudul “Relationship” dari pengguna bernama “John” dengan satu query berikut:

Keuntungan dari denormalisasi data adalah kecepatan. Hal tersebut dikarenakan masing-masing dokumen berisi semua informasi yang diperlukan dalam menentukan apakah data yang ditemukan cocok dengan yang dicari dalam bentuk query sehingga tidak diperlukan lagi join index yang kompleks.

2.1.4

RESTful Application Programming Interface (API) REST adalah koleksi dari prinsip dimana sering disebut sebagai kumpulan standar. Gaya arsitektur dari REST menggambarkan 6 batasan, yaitu: Uniform Interface, Stateless, Cacheable, Client-Server, Layered System, dan Code on Demand. Perlu diketahui bahwa, batasan yang opsional dari arsitektur REST adalah Code on Demand. Jika sebuah service melanggar batasan lain, maka itu tidak akan dapat diaggap sebagai RESTful. Menurut Gormley & Tong (2015), semua bahasa lain dapat berkomunikasi dengan Elasticsearch melalui port 9200 menggunakan Resful API, dapat diakses dengan klien web favorit. Kita bahkan bisa berbicara

dengan

Elasticsearch

melalui

command

line

dengan

menggunakan perintah curl. Request untuk Elasticsearch terdiri dari bagian yang sama seperti HTTP request:

Bagian yang ditandai dengan < > diatas adalah:


VERB Metode HTTP atau verb yang sesuai: GET, POST, PUT, atau DELETE. Penjelasan dari metode HTTP diatas dapat dijelaskan sebagai berikut (Fredrich, 2012): 1.

GET Metode HTTP GET digunakan untuk mengambil (atau membaca) representasi sumber daya. GET (dan HEAD) bersifat idempoten, yang berarti membuat beberapa permintaan identik yang berakhir dengan hasil yang sama seperti satu permintaan tunggal. Contoh: GET http://www.example.com/customers/12345/orders

2.

POST Kata kerja POST paling sering digunakan untuk pembuatan sumber daya baru. Secara khusus, ini digunakan untuk menciptakan sumber daya subordinate. Membuat dua permintaan POST yang identik kemungkinan besar akan menghasilkan dua sumber yang berisi informasi yang sama. Contoh: POST http://www.example.com/customers/12345/orders

3.

PUT PUT paling sering digunakan untuk kemampuan update, PUT ke sumber daya URI yang dikenal dengan badan permintaan yang berisi representasi sumber asli yang baru diperbarui. PUT juga dapat digunakan untuk membuat sumber daya pada kasus di mana ID sumber daya dipilih oleh klien dan bukan oleh server. Contoh: PUT http://www.example.com/customers/12345/orders/9876

4.

DELETE DELETE

digunakan

untuk

menghapus

sumber

daya

yang

diidentifikasi oleh URI. HTTP-spec-wise, operasi DELETE bersifat idempoten. Jika menghapus sebuah sumber daya, itu akan terhapus. Berulang kali memanggil DELETE pada sumber daya itu akan berakhir sama, yaitu sumbernya hilang. Contoh: DELETE http://www.example.com/customers/12345/orders


PROTOCOL Baik http atau https (jika memiliki proxy https di depan Elasticsearch). HOST Nama host dari setiap node pada cluster Elasticsearch, atau localhost untuk sebuah node pada komputer lokal. PORT Port yang menjalankan layanan HTTP Elasticsearch, secara default 9200. QUERY_STRING Parameter query-string pilihan. BODY Sebuah badan JSON-encoded request (jika request membutuhkan). 2.1.5

Hypertext Transfer Protocol (HTTP) Menurut Nixon (2014), Hypertext Transfer Protocol (HTTP) adalah protokol standar yang mengatur permintaan browser dari komputer client, juga respon dari server. Tugas dari web server adalah untuk memberikan respon yang mempunyai makna biasanya memberikan respon atas permintaan client. Diantara client dan server dimungkinkan adanya adanya perangkat-perangkat lain seperti router, proxy, gateway, dan lain sebagainya. Perangkat tersebut mempunyai tugas untuk mengatur permintaan dan respon diarahkan ke client dan server yang benar.

2.1.6

JavaScript Object Notation (JSON) Elasticsearch menggunakan JavaScript Object Notation, atau JSON, sebagai format serialisasi untuk dokumen. Pemrograman JSON didukung oleh sebagian besar bahasa pemrograman, dan telah menjadi format standar yang digunakan oleh gerakan NoSQL. Sederhana, ringkas, dan mudah dibaca. Mengkonversi objek ke JSON untuk pengindeks-an dalam Elasticsearch jauh lebih sederhana daripada proses yang setara dengan struktur tabel datar. Hampir semua bahasa memiliki modul yang akan mengubah struktur data atau objek menjadi JSON untuk, namun rinciannya spesifik untuk setiap bahasa (Gormley & Tong, 2015).


2.1.7

NoSQL NoSQL, yang berarti "not only SQL", adalah sebuah gerakan yang mendorong pengembang dan pelaku bisnis untuk membuka pikiran mereka dan mempertimbangkan kemungkinan baru di luar pendekatan relasional klasik terhadap persistensi data. Dengan NoSQL, berbagai masalah data untuk bagian-bagian berikut menjadi lebih mudah untuk diselesaikan:

Kinerja,

Skalabilitas,

Footprint

yang

Lebih

Kecil,

Produktivitas Pengembang, Fleksibilitas Skema. Untuk meringkas opsi NoSQL, berikut merupakan beberapa model atau kategori yang paling umum (Orient Technologies, 2017): 

Key/Value databases: model data dikurangi menjadi tabel hash sederhana yang terdiri dari pasangan key / value. Hal ini sering mudah didistribusikan di beberapa server. Produk yang paling dikenal dari kelompok ini meliputi Redis, Dynamo, dan Riak.



Column-oriented databases: data disimpan di bagian kolom yang menawarkan fleksibilitas dan agregasi yang lebih mudah. Cassandra dari Facebook, Google's BigTable, dan SimpleDB dari Amazon adalah beberapa contoh database berorientasi kolom.



Document databases: model data terdiri dari koleksi dokumen dimana masing-masing dokumen dapat memiliki beberapa bidang tanpa harus menentukan skema. Produk yang paling dikenal dari kelompok ini adalah MongoDB dan CouchDB.



Graph databases: model domain terdiri dari vertices yang saling terkait oleh edge untuk menciptakan struktur grafik yang kaya. Produk yang paling dikenal dari kelompok ini adalah OrientDB dan Neo4j.

2.2.

Pengembangan Sistem

2.2.1

Software Development Life Cycle (SDLC) Menurut Satzinger, Jackson, & Burd (2012), SDLC merupakan siklus hidup

dari

keseluruhan

proses

dari

pengembangan,

pengerjaan,

penggunaan, dan pembaharuan sebuah sistem informasi.


Systems Development Life Cycle (SDLC) mengidentifikasi semua aktivitas yang dibutuhkan untuk membangun, menjalankan, serta memelihara sebuah sistem informasi. Normalnya, SDLC mengikutsertakan semua aktivitas-aktivitas yang merupakan bagian dari systems analysis, systems design, programming, testing, dan maintaining, yang sebagaimana termasuk di dalam proses-proses project management. Beberapa jenis pendekatan yang diterapkan di dalam SDLC: 1.

Predictive approach, pendekatan SDLC yang mengasumsikan bahwa pengembangan proyek dapat direncanakan dan diorganisir terlebih dahulu, sehingga sistem informasi baru yang akan dikembangkan dapat dibangun sesuai dengan perencanaan yang telah dibuat sebelumnya.

2.

Adaptive approach, pendekatan SDLC yang lebih fleksibel, yang mengasumsikan

bahwa

pengembangan

proyek

tidak

dapat

direncanakan secara menyeluruh terlebih dahulu, akan tetapi perencanaan proyek tersebut harus dimodifikasi secara terus-menerus seiring jalannya pengembangan proyek.

Gambar 2.1 Predictive dan Adaptive SDLC (Satzinger, Jackson, & Burd, 2012:227228)

2.2.2

Agile Menurut Ambler & Holitza (2012), Agile adalah usaha untuk membuat proses pengembangan perangkat lunak menjadi lebih baik dan lebih efektif, dan hal itu terlihat semakin populer dan sukses. Agile adalah pendekatan incremental, iteratif untuk menghadirkan perangkat lunak berkualitas tinggi dengan hasil yang sering untuk memastikan nilai selama proses berlangsung. Ini memberi nilai tinggi pada individu, kolaborasi, dan kemampuan untuk merespons perubahan. Agile sendiri hanyalah koleksi 28 http://digilib.mercubuana.ac.id/

metodologi yang baru dan terbaik yang digunakan untuk mengembangkan dan memelihara perangkat lunak. Tim menemukan kesuksesan dengan pendekatan

yang

tetap

sesuai

dengan

prinsip

inti

Agile

dan

memperpanjangnya melampaui tahap pengembangan perangkat lunak ke keseluruhan siklus hidup perangkat lunak. Berikut adalah peran-peran yang ada pada Agile Development: a. Stakeholder, seseorang yang mengalami dampak finansial akibat solusi dan jelas lebih dari sekedar pengguna akhir b. Product Owner, mewakili kebutuhan dan keinginan komunitas stakeholder kepada delivery team. c. Team Member, berfokus untuk menghasilkan solusi bagi yang sebenarnya bagi stakeholder. d. Team Lead, membimbing tim dalam melakukan manajemen daripada mengambil tanggung jawab tersebut sendiri e. Architecture Owner, seseorang yang harus bertanggung jawab untuk memastikan tim dapat mengurangi risiko proyek. f. Agile Mentor, menerapkan proyek agile dan berbagi pengalaman itu dengan tim proyek. Berikut merupakan aktivitas yang terjadi dalam Agile Development: a. Perencaan Agile Biasanya terdiri dari 3 bagian yaitu Release Planning, Iteration Planning, dan Daily Planning. b. Menghadiri Rapat Harian Melakukan perencanaan atas proyek harian dan biasanya dilakukan selama 15 menit setiap harinya. Yang dibahas dalam setiap rapat adalah, Apa yang dilakukan kemarin, Apa yang akan dikerjakan hari ini, dan Apa saja hambatan yang ditemukan. c. Membuat User Story Stakeholder akan membuat user story jika ada produk/fitur baru yang diinginkan dengan format:


Gambar 2.2 Format User Story (Ambler & Holitza, 2012:17)

d. Estimasi pekerjaan Tim Agile memperoleh konsistensi dengan menggunakan nilai point yang tidak berbeda berdasarkan kemampuan orang yang melakukan pekerjaan. Tim masih mengakomodasi anggota tim yang lebih cepat dan lebih lambat dalam jumlah poin yang diberikan dalam satu iterasi, namun nilai yang diberikan kepada pemilik produk dan stakeholder (diukur dengan ukuran dan kompleksitas) tetap konsisten. e. Melacak Kecepatan Pada akhir setiap iterasi, tim agile melihat persyaratan telah selesai dan menambahkan jumlah story point yang terkait dengan persyaratan tersebut. Jumlah total story point yang lengkap menjadi kecepatan tim. f. Mengukur Kemajuan dengan Laporan Burndown Laporan Burndown melacak jumlah poin yang telah selesai dan digunakan untuk memantau iterasi tunggal, rilis, dan seluruh proyek backlog. g. Test Driven Development Tim agile menulis banyak tes unit, mengotomatisasi mereka, dan menjalankannya secara berkala melawan kode yang mereka tulis sebagai individu dan melawan kode gabungan mereka yang membentuk keseluruhan aplikasi. h. Integrasi dan Pengerjaan yang Terus Menerus Continuous

integration

merupakan

praktek

secara

teratur

mengintegrasikan dan menguji solusi Anda untuk memasukkan perubahan dibuat untuk definisinya Continuous deployment meningkatkan CI dengan secara otomatis menggelar bangunan sukses. i. Menyajikan Hasil pada Review Iterasi 30 http://digilib.mercubuana.ac.id/

Persiapan untuk pertemuan review iterasi seharusnya tidak dilakukan lebih dari beberapa menit. Tinjauan iterasi berfokus pada menunjukkan apa yang telah dilakukan tim pengembang. j. Mengumpulkan feedback dalam iterasi Rapat Review Mengumpulkan iterasi review feedback secara informal. Product Owner atau Team Lead dapat mencatat atas nama perkembangannya tim, karena anggota tim sering terlibat dalam presentasi dan menghasilkan percakapan. k. Belajar dan Meningkatkan Iterasi Retrospektif Iterasi retrospektif adalah pertemuan dimana the team lead, product owner, dan tim pengembang mendiskusikan bagaimana iterasi tersebut berjalan dan apa yang dapat mereka lakukan untuk memperbaiki iterasi berikutnya. 2.2.3

Scrum Scrum adalah salah satu komponen dari metodologi pengembangan Agile. Scrum merupakan kerangka berpikir dalam mengembangkan software yang memberi penekanan pada self-organization dan semangat kolektivitas. Scrum menguraikan proses untuk mengidentifikasi dan katalogisasi pekerjaan yang perlu dilakukan, memprioritaskan pekerjaan yang perlu dilakukan, dan pelaksanaan pekerjaan menggunakan rilis iteratif (dinamakan dengan sprint) dan memiliki tujuan utama untuk mendapatkan perkiraan berapa lama proses pembangunan sistem akan berlangsung. Menurut (Partogi, 2015), Sprint adalah jantung dari scrum. Durasi sprint biasanya dibatasi maksimal hingga 30 hari untuk membatasi resiko dimana

pasar

sudah berubah

dan menyebabkan

software

yang

dikembangkan sudah tidak relevan dengan keadaan di pasar. Semua acara dalam sprint memiliki batasan waktu (time box) yang dapat dilihat pada tabel berikut. Tabel 2.1 Durasi dalam setiap Sprint

Sprint

Planning

Review

Retrospective

Daily Scrum

30 hari

8 jam

4 jam

3 jam

15 menit


Sprint

Planning

Review

Retrospective

Daily Scrum

3 minggu

~6 jam

~3 jam

~2 jam 15 menit

15 menit

2 minggu

~4 jam

~2 jam

~1.5 jam

15 menit

1 minggu

~2 jam

~1 jam

~45 menit

15 menit

Penjelasan untuk setiap sprint diatas akan diuraikan sebagai berikut: 1. Sprint Planning Merupakan aktivitas untuk membuat rencana mengenai Product Backlog Item (PBI) yang akan dikembangkan oleh tim pengembang selama satu sprint berjalan. Pada saat sprint planning, tim pengembang

membua

estimasi

selama

satu

sprint

kedepan

berdasarkan pengalaman ataupun perasaan. 2. Sprint Review Merupakan aktivitas yang dijalankan oleh tim scrum dan stakeholder di akhir sprint untuk mengetahui produk apa saja yang sudah selesai ataupun belum selesai pada sprint tersebut. Pada sprint ini juga dilakukan presentasi untuk PBI yang sudah selesai oleh tim pengembang, pelaksanaan review produk di pasaran, review timeline, budget dan lainnya. 3. Sprint Retrospective Merupakan aktivitas yang difasilitasi oleh Scrum Master untuk mendiskusikan bagaimana proses membangun software dalam sprint. Adapun poin diskusi utama dalam retrospective adalah hal apa yang berjalan dengan baik selama siklus sprint yang perlu dipertahankan, apa saja hal yang salah yang perlu dihentikan, serta apa perubahan yang perlu dimulai untuk meningkatkan sprint berikutnya. 4. Daily Meeting Merupakan aktivitas yang dilakukan setiap harinya oleh tim pengembang untuk memberitahu seluruh tim terkait informasi terbaru dari pengembangan sistem selama sprint berjalan. Terdapat 3 pertanyaan yang umumnya didiskusikan dalam daily meeting, yaitu: a.

Apa yang sudah dikerjakan sejak daily meeting terakhir?


b.

Apa rencana yang akan diselesaikan pada daily meeting berikutnya?

c.

Apa hambatan yang dialami?

Tim dalam Scrum dibagi menjadi 3 bagian, yakni: 1.

Scrum Master, seorang servant leader yang membantu timnya menjadi tim terbaik. Scrum Master tidak menugaskan pekerjaan ataupun mengelola orang-orang namun mengelola strategi menuju agility, proses scrum, dan segala hambatan yang ada di dalamnya.

2.

Product Owner, seorang manajer dalam scrum yang bertugas dalam mengelola produk untuk meningkatkan nilai valuasi perusahaan di pasar. Product Owner berperan dalam memaksimalkan nilai bisnis untuk perusahaan melalui software yang dibangun oleh tim pengembang.

3.

Tim Pengembang, sekelompok tim yang secara kesatuan berperan dalam mengembangkan software. Tim tersebut dapat terdiri dari solution architect, test engineer, UX designer, web dan UI designer, database administrator, business analyst, technical writer, software engineer, security engineer, serta build and employment engineer. Namun secara umum, scrum tidak mengenal adanya jabatan-jabatan khusus dalam tim pengembang.

Scrum mendefinisikan dua tingkatan artefak yakni: 1.

Product Backlog Product Backlog berisi daftar rencana mengenai apa yang akan ada di dalam produk. Semua hal yang perlu dilakukan agar produk bernilai tinggi, dimasukkan dalam satu tumpukan Product Backlog agar semua pihak yang memiliki kepentingan terhadap software dapat melihat roadmap dari pengembangan produk. Product Backlog kemudian akan diurutkan oleh Product Owner namun tim pengembang tetap dapat memberikan saran yang dapat membantu. Setiap bagian dari Product


Backlog dinamakan dengan Product Backlog Item (PBI). PBI biasanya didetailkan untuk 3 sprint ke depan. 2.

Sprint Backlog Sprint Backlog berisi daftar rencana mengenai bagaimana tim pengembang akan berkolaborasi selama satu sprint ke depan untuk mengembangkan subset dari Product Backlog. Sprint Backlog berisi PBI yang disepakati tim pengembang bersama product owner untuk dikerjakan selama satu sprint beserta taktik untuk mengerjakannya. Tim pengembang memiliki otoritas penuh untuk menugaskan sprint backlog tersebut kepada diri mereka sendiri. Setiap hari tim pengembang memantau pergerakan dari sprint backlog menuju sprint goal (tujuan yang harus dicapai oleh tim pengembang selama sprint berlangsung)

dalam

daily

scrum.

Tim

pengembang

dapat

menambahkan atau mengurangi item dari sprint backlog asalkan tetap mencapai sprint goal. Kemudian, pada setiap akhir sprint dapat ditampilkan sebuah diagram yang disebut dengan burndown chart. Diagram burndown adalah representasi grafis dari jumlah pekerjaan yang harus diselesaikan (estimasi waktu pengerjaan) berbanding dengan timeline pada setiap iterasi. Garis yang ditampilkan dalam grafik adalah garis ideal work remaining line dibandingkan dengan actual work remaining line.

2.3.

Unified Modelling Languange (UML)

2.3.1

Pengertian UML Menurut Satzinger, Jackson, & Burd (2012), Unified Modelling Language (UML) merupakan standar kontruksi model dan notasi dikembangkan secara khusus untuk pengembangan berorientasi objek. Dengan menggunakan UML, dapat membuat model untuk semua jenis piranti lunak. UML muncul karena adanya kebutuhan pemodelan visual untuk

menspesifikasikan,

menggambarkan,

membangun,

dan

mendokumentasi sistem perangkat lunak. Berdasarkan pendapat yang dikemukakan di atas dapat ditarik kesimpulan bahwa UML adalah sebuah


bahasa yang berdasarkan grafik atau gambar untuk menvisualisasikan, menspesifikasikan, membangun dan mendokumentasikan sebuah sistem pengembangan perangkat lunak berbasis obyek (object oriented programming). 2.3.2

Use Case Diagram Use case diagram adalah model UML yang digunakan untuk menampilkan use cases dan hubungan mereka secara grafis dengan pengguna. Di UML, orang tersebut dinyatakan sebagai aktor. Aktor selalu berada di luar automation boundary sistem namun bisa juga menjadi bagian dari manual sistem. Terkadang, aktor dari use case bukanlah orang; melainkan, sistem atau perangkat lain yang menerima layanan dari sistem. Aktor direpresentasikan dengan gambar tongkat manusia sederhana. Tongkat manusia itu akan diberi nama yang kemudian menjadi ciri peran aktor tersebut. Use case itu sendiri digambarkan dalam bentuk oval dengan nama use case di dalamnya. Garis penghubung antara aktor dan use case menunjukkan bahwa aktor tersebut terlibat dengan use case terkait. Automation boundary, yang mendefinisikan batas antara bagian komputerisasi dari aplikasi dengan orang yang mengoperasikan aplikasi, digambarkan dengan sebuah persegi panjang berisi use case. Komunikasi aktor dengan use case melintasi automation boundary (Satzinger, Jackson, & Burd, 2012). Berikut merupakan contoh tampilan dari Use Case Diagram.

Gambar 2.3 Use Case Diagram (Satzinger, Jackson, & Burd, 2012:81)


2.3.3

Use Case Description Menurut Satzinger, Jackson, & Burd (2012), masing-masing use case yang telah teridentifikasi perlu dijabarkan lagi lebih mendetil agar memperoleh suatu gambaran utuh untuk eksekusi dari setiap use case. Penjabaran mendetil dari use case tersebut dicerminkan dalam use case description. Use case description merupakan deskripsi yang menjelaskan detil pemrosesan untuk sebuah use case. Banyaknya use case description yang dibuat, pada umumnya disesuaikan dengan jumlah use case yang ada. Salah satu jenis use case description adalah Fully Developed Description. Jenis ini mendeskripsikan secara detil informasi dari sebuah use case yang penjelasannya dapat dilihat sebagai berikut:  Use case name, merupakan nama dari use case yang akan dijelaskan pada use case description.  Scenario, merupakan nama skenario dari use case yang akan dijelaskan. Pada umumnya nama skenario dapat disamakan dengan nama dari use case terkait.  Triggering event, merupakan event yang memicu terjadinya use case.  Brief description, merupakan ringkasan singkat secara umum dari use case yang akan dijelaskan.  Actors, merupakan para pelaku atau pengguna sistem yang terkait dengan jalannya sebuah use case.  Related use cases, merupakan use cases lain yang ada keterkaitannya dengan use case yang dijelaskan saat ini.  Stakeholders, merupakan pihak-pihak yang berkepentingan dengan jalannya use case yang akan dijelaskan.  Preconditions, merupakan kondisi awal yang harus terpenuhi agar eksekusi dari use cases dapat terlaksana.  Postconditions, merupakan kondisi yang terjadi setelah use cases selesai dieksekusi.  Flow of activities, mendeskripsikan rincian aliran aktivitas-aktivitas yang terlaksana dari use cases, yang digambarkan secara berurutan. 36 http://digilib.mercubuana.ac.id/

Flow of activities juga akan menggambarkan interaksi aktivitas yang dilakukan oleh actor dengan sistem.  Exception condition, mendeskripsikan aktivitas-aktivitas khusus yang terjadi apabila suatu kondisi tidak terpenuhi pada saat eksekusi dari sebuah use case.

Gambar 2.4 Fully Developed Description (Satzinger, Jackson, & Burd, 2012:123)

2.3.4

Domain Model Class Diagram Class diagram digunakan untuk menunjukkan objek class untuk sistem. Notasinya dari Unified Modelling Language (UML), yang telah menjadi standar untuk model yang digunakan dengan pengembangan system object oriented. Salah satu jenis class diagram UML menunjukkan hal-hal dalam pekerjaan domain user disebut sebagai domain model class diagram. Tipe lain dari notasi class diagram UML digunakan untuk


membuat desain class diagram ketika merancang class dari sistem (Satzinger, Jackson, & Burd, 2012). Pada class diagram, notasi persegi panjang akan mewakili class sementara notasi garis yang menghubungkan persegi panjang akan menunjukkan asosiasi antara class. Notasi persegi panjang (kotak) terdiri dari dua bagian, dimana bagian atas berisi nama class, dan bagian bawah berisi atribut class. Nama class selalu diawali dengan huruf kapital, dan nama atribut selalu diawali dengan huruf kecil. Berikut merupakan contoh Domain Model Class Diagram.

Gambar 2.5 Contoh Domain Model Class Diagram (Satzinger, Jackson, & Burd, 2012:103)

2.4.

Ruang Lingkup Pemrograman

2.4.1

Hypertext Preprocessor (PHP) Menurut Nixon (2014), PHP adalah bahasa pemrograman yang digunakan untuk membuat server menghasilkan keluaran output dinamis yang berpotensi berbeda setiap kali browser melakukan pencarian kembali sebuah halaman. PHP hadir dengan ratusan fungsi built-in yang siap digunakan, hal inilah yang membuatnya menjadi bahasa yang sangat kaya. Dengan PHP, menanamkan aktivitas dinamis di halaman web menjadi sesuatu hal yang sederhana. Dengan memberi halaman ekstensi .php, mereka akan memiliki akses instan ke bahasa scripting. Dari sudut pandang pengembang, yang perlu dilakukan adalah menulis kode seperti berikut.


Tag awal . Di luar bentuk ini, semuanya dikirim ke klien sebagai HTML langsung. Jadi teks „Here's the latest news‟ adalah output ke browser; dalam tag PHP, fungsi tanggal yang built-in menampilkan hari dalam minggu ini sesuai dengan waktu sistem server. Hasil akhir dari dua kode diatas akan terlihat seperti berikut.

2.4.2

CodeIgniter (CI) CodeIgniter adalah kerangka kerja PHP open source yang kuat dengan footprint yang sangat kecil, dibangun untuk pengembang yang membutuhkan toolkit sederhana dan elegan untuk membuat aplikasi web berfitur lengkap. CodeIgniter memiliki seperangkat fungsionalitas yang sangat kaya, yang akan meningkatkan kecepatan kerja pengembangan situs web. Jika Anda tahu PHP dengan baik, maka CodeIgniter akan mempermudah tugas Anda. CodeIgniter memiliki sejumlah libraries dan helpers yang sangat kaya. Dengan menggunakan CodeIgniter, akan menghemat banyak waktu, jika sedang mengembangkan situs web dari nol. Tidak hanya itu, sebuah situs yang dibangun di CodeIgniter juga aman, karena memiliki kemampuan untuk mencegah berbagai serangan yang terjadi melalui situs web (Tutorials Point, 2015).

2.4.3

JavaScript JavaScript

adalah

sebuah

bahasa

scripting

client-side

yang

keseluruhannya berjalan pada web browser. JavaScript membawa fungsionalitas yang dinamis pada halaman web. Setiap kali terjadi perubahan ketika pointer mouse diarahkan ke sebuat item dalam halaman web, atau ketika kita melihat teks yang baru, warna, maupun sebuah gambar yang muncul di halaman, atau mengambil sebuah obyek pada


halaman dan kemudian memindahkannya ke lokasi baru, semua hal tersebut dilakukan oleh JavaScript. Penggunaan Javascript akan lebih optimal jika elemen HTML ditulis secara formal dan terstruktur. Penggunaan JavaScript itu sendiri, dengan cara menempatkan awalan <script> dan akhiran di antara label HTML. Berbeda dengan penulisan bahasa lainnya, tidak ada semicolon (;) di akhir penulisan Javascript. Ini dikarenakan oleh baris baru yang diartikan sebagai semikolon. Tetapi jika dalam satu baris terdapat lebih dari satu statement, maka perlu dituliskan semicolon pada akhir setiap statement kecuali statement terakhir (Nixon, 2014). 2.4.4

Cascading Style Sheets (CSS) Cascading Style Sheet (CSS), dapat kita gunakan untuk mengubah tampilan-tampilan pada halaman web untuk membuatnya terlihat sebagaimana yang diinginkan. Dengan CSS dan integrasinya dengan Data Object Model (DOM), restyle elemen-elemen dapat diubah dengan mudah. Dijelaskan ada beberapa macam tampilan CSS yang berbeda dalam penggunaannya, dimulai dari tampilan default yang telah disediakan oleh browser, melalui inline, sampai ke tampilan eksternal (Nixon, 2014).

2.4.5

Hypertext Markup Language (HTML) Hypertext Markup Language (HTML) adalah sebuah bahasa penulisan yang diciptakan oleh Berners-Lee untuk menampilkan halaman dari sebuah web browser. HTML disimpan dengan format ekstensi file .htm atau .html (Nixon, 2014).

2.4.6

Apache Web Server Menurut Nixon (2014), tugas dari web server adalah untuk memberikan respon yang mempunyai makna biasanya memberikan respon atas permintaan client. Apache tidak menyajikan hanya file HTML, namun juga menangani berbagai macam file mulai dari gambar dan file Flash hingga file audio MP3, RSS (Really Simple Syndication) feeds, dan sebagainya. Untuk melakukan ini, setiap elemen yang ditemukan web client di halaman HTML juga diminta dari server, dan kemudian menyajikannya. Apache juga mendukung sejumlah besar modulnya


sendiri. Selain modul PHP, yang paling penting untuk tujuan sebagai programmer web adalah modul yang menangani keamanan. Contoh lainnya adalah modul Rewrite, yang memungkinkan web server menangani berbagai jenis URL dan menuliskannya kembali ke persyaratan internalnya sendiri, serta modul Proxy, yang dapat digunakan untuk menyajikan halaman yang sering diminta dari cache untuk memudahkan muatan di server. 2.4.7

Model-View-Controller (MVC) Menurut Aygun (2015) Model-View-Controller (MVC) adalah sebuah desain pola yang digunakan dalam rekayasa perangkat lunak. Hal ini didasarkan pada abstraksi model dan view pada aplikasi yang kompleks dimana data dalam jumlah besar disajikan kepada pengguna. Model dan view dapat diatur tanpa mempengaruhi satu sama lain. Model-ViewController memecahkan masalah ini menggunakan mediator yang disebut controller dengan mengisolasi data access dan business logic dari tampilan data dan interaksi pengguna. Menurut Mugisha (2014), Model-View-Controller merupakan pola arsitektur yang digunakan untuk mengimplementasikan user interface. Perangkat lunak dibagi menjadi tiga bagian (Model, View dan Controller) yang saling terhubung, seperti pada gambar dibawah.

Gambar 2.6 Komponen MVC (Mugisha, 2014:1)

Berikut ini merupakan detail interaksi antara komponen dalam pola perancangan MVC:


1.

Controller  Controller terlibat dalam perubahan state model.  Controller mendapatkan input dari mouse dan keyboard dari user dan mengarahkan model dan view untuk berubah sesuai kebutuhan.  Controller

menginterpretasikan

interaksi

dari

view

dan

menerjemahkannya ke dalam aksi yang dilakukan oleh model.  Controller juga bertanggung jawab untuk menampilkan view yang sesuai untuk user yang sesuai. 2.

Model  Model merupakan obyek yang merepresentasikan suatu aktivitas ataupun tabel dalam database.  Model mengelola behavior dan juga data dari aplikasi perangkat lunak.  Model menerima permintaan untuk mendapatkan informasi dan merespon instruksi untuk mengubah status.  Model menampilkan data aplikasi beserta rule yang mengatur akses untuk memperbarui data.  Model menampilkan keadaan dan sifat-sifat dari tiap komponen, serta mengatur perubahan keadaan tersebut.

3.

View  View merupakan representasi visual dari model.  View menerjemahkan isi model dengan mengakses data dari model dan menentukan cara untuk menampilkan data.  View mengatur representasi output grafis dan tekstual dari aplikasi perangkat lunak.  View biasanya menempel pada model yang bersesuaian dan isi dari model tersebut untuk ditampilkan.

2.5.

Ruang Lingkup Basis Data

2.5.1

Basis Data Basis data adalah sekumpulan data yang saling berhubungan satu dengan yang lain secara logikal, dan deskripsi dari data ini dirancang 42 http://digilib.mercubuana.ac.id/

untuk memenuhi kebutuhan informasi dari sebuah organisasi. Basis data relasional adalah sebuah kumpulan dari hubungan yang dinormalisasi dengan nama relasi yang berbeda. Basis data relasional terdiri dari relasi yang terstruktur dengan tepat. Biasanya disebut dengan proses normalisasi (Connoly & Begg, 2015). 2.5.2

MySQL Menurut Nixon (2014), MySQL adalah sebuah sistem manajemen database yang mungkin paling populer untuk web servers. Itu dikarenakan fakta bahwa seperti PHP, MySQL gratis untuk digunakan oleh siapapun. Disamping itu MySQL sangat powerful dan cepat, bisa berjalan pada perangkat keras yang sederhana dan efisien dalam penggunaan sumber daya. MySQL dikembangkan pada pertengahan tahun 1990, yang sekarang merupakan teknologi database yang paling banyak digunakan untuk tujuan internet saat ini. Sebuah database MySQL memiliki satu atau lebih tabel, dimana setiap tabelnya berisi arsip-arsip atau baris. Dalam setiap baris terdapat berbagai macam kolom yang berisikan data itu sendiri. Perhatikan contoh tabel berikut: Tabel 2.2 Contoh Tabel Sederhana

Author

Title

Type

Year

Mark Twain

Adventures of Tom

Fiction

1876

Sawyer Jane Austen

Pride and Prejudice

Fiction

1811

Charles Darwin

The Origin of Species

Non-Fiction

1856

Charles Dickens

The old Curiosity Shop

Fiction

1841

William

Romeo and Juliet

Play

1594

Shakespeare

Setiap baris pada tabel diatas sama seperti baris pada MySQL, dan setiap elemen dalam baris sama dengan field pada MySQL. Terdapat SQL (Structured Query Language) yaitu bahasa yang mirip bahasa Inggris yang didesain untuk meminta data tertentu dari database, berikut contohnya: SELECT title FROM publications WHERE author = ‘Jane Austen’; 43 http://digilib.mercubuana.ac.id/

Secara bahasa dapat diartikan bahwa perintah SQL diatas bertujuan untuk meminta data atau kolom “title” dari tabel “publications” dengan author “Jane Austen”. Istilah-istilah yang penting untuk diingat dalam pembuatan database adalah: 1.

Database merupakan wadah keseluruhan yang memuat kumpulan data MySQL.

2.

Table merupakan sub wadah dalam database yang memuat data sebenarnya.

3.

Row merupakan sebuah baris tunggal dalam sebuah tabel yang memuat beberapa kolom.

4. 2.5.3

Column merupakan nama dari data atau konten pada sebuah baris.

MongoDB MongoDB adalah sistem manajemen basis data yang dirancang untuk secara cepat mengembangkan aplikasi web dan infrastruktur internet. Model data dan strategi dibangun untuk kemampuan „membaca dan menulis‟ yang tinggi

melalui

put

dan kemampuan untuk

menyesuaikan diri dengan failover otomatis. MongoDB dapat memberikan kinerja yang sangat bagus, baik itu ketika aplikasi hanya membutuhkan satu simpul basis data atau lebih. Format dokumen MongoDB didasarkan pada JSON, skema populer untuk menyimpan struktur data dengan bebas. JSON adalah akronim dari JavaScript Object Notation yang strukturnya terdiri dari kunci dan nilai. MongoDB dirancang untuk menggabungkan fitur terbaik dari key-value stores dan basis data relasional. Karena kesederhanaannya, key-value stores sangat cepat dan relatif mudah untuk diukur. Basis data relasional lebih sulit untuk skala, setidaknya secara horizontal, namun memiliki model data yang kaya dan bahasa query yang kuat. MongoDB sangat sesuai sebagai datastore utama untuk aplikasi web, analisis dan aplikasi logging, dan aplikasi yang memerlukan

cache

mediumgrade.

Selain

itu,

karena

dengan

kemudahannya menyimpan data yang schema-less, MongoDB juga bagus dalam menangkap data yang strukturnya belum bisa diketahui sebelumnya (Kyle Banker, 2016).


Replikasi adalah distribusi dan pemeliharaan data di beberapa server MongoDB (node). MongoDB dapat menyalin data ke satu atau lebih node dan terus membuat mereka tetap sinkron saat terjadi perubahan. Jenis replikasi ini diberikan melalui mekanisme yang disebut replika set, dimana sekelompok node dikonfigurasi untuk menyinkronkan data mereka secara otomatis dan gagal saat simpul hilang. Replika adalah strategi replikasi MongoDB yang direkomendasikan. Konfigurasi replika set minimum yang direkomendasikan terdiri dari tiga node, Karena dalam bentuk replika hanya dengan dua node, tidak dapat memiliki mayoritas jika server utama turun. Ketiga anggota replika set dapat memiliki data atau dua anggota yang menyimpan data dan arbiter. Berikut adalah contoh replika set sederhana yang terdiri dari primary, secondary, dan arbiter.

Gambar 2.7 Replika set dasar yang terdiri dari Primary, Secondary, dan Arbiter (Kyle Banker, 2016:301)

2.5.4

Entity Relationship Diagram (ERD) Menurut Satzinger, Jackson, & Burd (2012), Entity Relationship Diagram

(ERD)

adalah

sekumpulan cara

atau

peralatan

untuk

mendeskripsikan data-data atau obyek-obyek yang dibuat berdasarkan dan berasal dari dunia nyata yang disebut entitas (entity) serta hubungan (relationship) antar entitas-entitas tersebut dengan menggunakan beberapa 45 http://digilib.mercubuana.ac.id/

notasi. ERD mendokumentasikan data entities apa saja yang perlu dicatat, diolah, disimpan, dan didistribusikan melalui sistem informasi yang akan dibangun. Data entities merupakan things yang dibutuhkan oleh sistem untuk disimpan informasinya. Berikut merupakan komponen-komponen ERD: 1.

Entity Merupakan individu yang mewakili suatu obyek dan dapat dibedakan dengan obyek lain.

2.

Attribut Merupakan properti yang dimiliki oleh suatu entity, dimana dapat mendeskripsikan karakteristik dari entity tersebut.

3.

Relationship Relationship pada ERD biasanya disebut dengn

cardinality.

Cardinality adalah jumlah kejadian (kemungkinan minimal dan maksimal) yang mungkin terjadi di dalam hubungan antara entity, contohnya seorang customer dapat memesan banyak orders dan seorang karyawan bekerja hanya di satu departemen.

Gambar 2.8 Relationship dalam ERD (Satzinger, Jackson, & Burd, 2012:99)

2.6.

Perbandingan Elasticsearch Setiap beban kerja divalidasi dengan 10 client thread yang digabungkan dengan catatan keseluruhan 1000, 20000, 40000, 60000, 80000 dan 100000. Masing-masing kombinasi ini diulang 20 kali. YCSB


secara default membuat 1000 kali pencatatan. Waktu eksekusi vs. jumlah record menggunakan 10 benang klien diukur.

Gambar 2.9 Insert Operation

Gambar 2.10 Update Operation


Gambar 2.11 Read Operation

2.6.1

OrientDB OrientDB adalah DBMS Open Source NoSQL pertama yang menyatukan kekuatan grafik dan fleksibilitas dokumen menjadi satu database operasional berkinerja tinggi yang terukur. OrientDB memiliki fitur DBMS Dokumen dan Grafik. Ditulis dalam bahasa pemrograman Java dan dirancang untuk menjadi sangat cepat: dapat menyimpan hingga 220.000 catatan per detik pada perangkat keras umum. Tidak hanya bisa menanamkan dokumen seperti database Dokumen lainnya, namun mengelola hubungan seperti Graph Database dengan koneksi langsung antar record. OrientDB mendukung mode schema-less, schema-full dan schema-mixed dan memiliki sistem pembuatan profil keamanan yang kuat berdasarkan user dan role (Orient Technologies, 2017). Berikut adalah penjelasan lebih detail terkait OrientDB: 

NoSQL Model Solusi berbasis NoSQL pada umumnya memberikan cara yang hebat, terukur, dan fleksibel untuk memecahkan kebutuhan data dan kasus penggunaan yang sebelumnya dikelola oleh basis data relasional. Tujuan Orient Technologies dalam membangun OrientDB adalah menciptakan basis data yang kuat dan berkinerja tinggi yang dapat


bekerja secara optimal dalam sejumlah kelompok use case yang memungkinkan. 

Multi Model Mesin OrientDB mendukung model Graph, Document, Key/Value, dan Object, sehingga OrientDB dapat digunakan sebagai pengganti produk dalam kategori ini. Namun alasan utama mengapa pengguna memilih OrientDB adalah kemampuannya untuk bertindak sebagai DBMS Multi-Model sejati dengan menggabungkan semua fitur dari keempat model menjadi satu.



Document Model Dokumen adalah sekumpulan pasangan key/value (juga disebut bidang atau properti) di mana kunci memungkinkan akses ke nilainya. Nilai dapat menyimpan tipe data primitif, dokumen yang di-embed, diputuskan

apakah

akan

menanamkan

dokumen

atau

menghubungkannya secara langsung. Saat mengambil dokumen, semua link dipecahkan secara otomatis oleh OrientDB. Ini adalah perbedaan yang paling penting dengan Database Dokumen lainnya seperti MongoDB. Tabel di bawah menggambarkan perbandingan antara model relasional, model dokumen, dan model dokumen OrientDB:

Gambar 2.12 Perbandingan Model Relasional, Model Dokumen, Model Dokumen OrientDB (Orient Technologies, 2017:9)



Graph Model Grafik mewakili struktur seperti jaringan yang terdiri dari Vertices (juga dikenal sebagai Node) yang saling terkait oleh Edges (juga dikenal sebagai Arcs). Model grafik OrientDB diwakili oleh konsep grafik properti, yang mendefinisikan vertex (entitas yang dapat


dihubungkan dengan vertices lainnya) dan edge (entitas yang menghubungkan dua vertices). Selain properti yang mandatori, masing-masing vertex atau edge juga bisa memegang satu set custom properti. Properti ini dapat didefinisikan oleh pengguna, yang dapat membuat

vertex

dan

edge

tampak mirip

dengan

dokumen.

Perbandingan antara model grafik, model data relasional, dan model grafik OrientDB:

Gambar 2.13 Perbandingan Model Grafik, Model Data Relasional, Model Grafik OrientDB (Orient Technologies, 2017:10)



Key/Value Model Segala sesuatu dalam basis data bisa didapat dengan kunci, dimana nilainya bisa dalam tipe sederhana maupun kompleks. OrientDB mendukung Dokumen dan Elemen Grafik sebagai nilai yang memungkinkan model yang lebih kaya daripada key/value klasik. Model key/value menyediakan "buckets" untuk mengelompokkan pasangan key/value dalam berbagai kontainer. Tabel di bawah menggambarkan perbandingan antara model relasional, model key/value, dan model key/value OrientDB:

Gambar 2.14 Perbandingan Model Relasional, Model Key/Value, Model Key/Value OrientDB (Orient Technologies, 2017:11)



Object Model


Model ini telah diwariskan oleh pemrograman berorientasi obyek dan mendukung Inheritance antar jenis (sub-types extend super-types), Polymorphism saat mengacu pada kelas dasar, dan Direct binding dari/ke obyek yang digunakan dalam bahasa pemrograman. Tabel di bawah menggambarkan perbandingan antara model relasional, model Obyek, dan model Obyek OrientDB:

Gambar 2.15 Perbandingan Model Relasional, Model Obyek, Model Obyek OrientDB (Orient Technologies, 2017:12)

2.6.2

Redis Redis adalah tipe basis data yang biasa disebut NoSQL atau nonrelational. Di Redis, tidak ada tabel, dan tidak ada data yang didasarkan atau ditentukan untuk menghubungkan data di Redis dengan data lain di Redis. Redis menjadi basis data non-relasional yang sangat cepat yang menyimpan pemetaan kunci ke lima jenis nilai yang berbeda. Redis mendukung penyimpanan yang tersimpan dalam memori pada disk, replikasi hingga skala membaca kinerja, dan sharding sisi klien untuk mengukur kinerja tulisan. Redis mendukung penulisan datanya ke disk secara otomatis dalam dua cara yang berbeda, dan dapat menyimpan data dalam empat struktur di samping tombol string polos seperti yang dilakukan oleh memcached. Perbedaan ini dan lainnya memungkinkan Redis untuk memecahkan masalah yang lebih luas, dan mengizinkan Redis digunakan sebagai basis data primer atau sebagai database pembantu dengan sistem penyimpanan lainnya. Jenis permintaan Redis adalah Perintah untuk setiap tipe data untuk pola akses umum, dengan operasi massal, dan dukungan transaksi parsial (Carlson, 2013). Dengan menggunakan Redis dan bukan basis data relasional atau lainnya terutama pada disk, penulisan data sementara yang tidak perlu dapat dihindari, keperluan untuk memindai dan menghapusnya data 51 http://digilib.mercubuana.ac.id/

sementara tersebut juga dapat dihindari, yang pada akhirnya akan meningkatkan kinerja. Berikut adalah struktur data yang tersedia dalam Redis.

Gambar 2.16 Struktur Data yang Tersedia di Redis (Carlson, 2013:8)

Meskipun Redis mampu berkinerja baik, karena desain in-memory nya, ada situasi di mana kita mungkin memerlukan Redis untuk memproses lebih banyak read queries daripada yang bisa ditangani oleh satu server Redis tunggal. Untuk mendukung tingkat kinerja read yang lebih tinggi (bersamaan dengan penanganan failover jika server dimana Redis dijalankan sedang crash), Redis mendukung replikasi master/slave dimana para slaves terhubung ke master dan menerima salinan awal dari keseluruhan basis data.

2.7.

Pengujian Sistem Menurut Pressman (2010), tujuan dari pengujian adalah untuk menemukan dan memperbaiki sebanyak mungkin kesalahan dalam program sebelum menyerahkan program kepada customer. Salah satu pengujian yang baik adalah pengujian yang memiliki probabilitas tinggi dalam menemukan kesalahan.

2.7.1

Black-box Testing Menurut Pressman (2010), pengujian black-box disebut juga pengujian perilaku, yang berfokus pada persyaratan fungsional perangkat


lunak yang memungkinkan developer menurunkan set kondisi input yang akan melaksanakan persyaratan fungsional untuk sebuah program. Pengujian black-box mencoba untuk menemukan kesalahan dalam kategori berikut: 1. Fungsi yang salah atau fungsi yang hilang 2. Kesalahan antarmuka (interface) 3. Kesalahan dalam struktur data atau akses database eksternal 4. Kesalahan perilaku (behaviour) dan kesalahan kinerja (performance) 5. Inisialisasi dan terminasi error Karena pengujian black-box sengaja mengabaikan struktur kontrol, perhatian difokuskan pada domain informasi. Pengujian tersebut dirancang untuk menjawab pertanyaan-pertanyaan berikut: 1.

Bagaimana validitas fungsional diuji?

2.

Bagaimana perilaku dan kinerja sistem diuji?

3.

Apa kelas input akan membuat kasus uji yang baik?

4.

Apakah sistem sangat sensitif terhadap nilai input tertentu?

5.

Bagaimana batas-batas kelas data diisolasi?

6.

Apa kecepatan data dan volume data yang dapat ditolerir oleh sistem?

7. Apa efek dari kombinasi spesifik data terhadap operasi sistem?


2.1. Konsep Elasticsearch

Recommend Documents