11 BAB III
METODOLOGI PENELITIAN DAN PERANCANGAN SISTEM
3.1 Metodologi Penelitian
Metodologi penelitian yang dilakukan dalam penelitian ini akan dilakukan pendekatan secara kuantitatif. Tahapan yang dilakukan dalam penelitian ini dapat diuraikan menjadi tahap studi fisibilitas dan wawancara, telaah literatur, tahap perancangan, tahap implementasi, tahap pengujian, dan tahap evaluasi.
a. Studi fisibilitas dan wawancara
Studi fisibilitas pada penelitian ini adalah dengan melakukan wawancara kepada Student Development kampus UMN. Wawancara dilakukan untuk mengetahui permasalahan dalam proses administrasi poin SKKM. Dari hasil wawancara didapatkan bahwa ada permasalahan dalam melakukan input SKKM UMN dari kegiatan luar kampus. Selain untuk mengetahui performa microservice yang diimplementasi dengan blockchain EOS, penelitian ini juga bertujuan memfasilitasi administrasi poin SKKM yang berasal dari kegiatan luar kampus.
b. Telaah Literatur
Di tahap telaah literatur telah ditemukan bagaimana performa RPM (Request Per Minute) yang didapat dari teknologi arsitektur microservice, yang diintegrasikan dengan teknologi blockchain EOS, teknologi blockchain EOS akan digunakan untuk administrasi sistem poin SKKM UMN.
12 c. Perancangan
Dalam memenuhi requirement yang dibutuhkan pada permasalahan SKKM di UMN (Universitas Multimedia Nusantara), akan dilakukan perancangan untuk menyelesaikan permasalahan poin SKKM UMN (Universitas Multimedia Nusantara). Sistem poin SKKM ini akan dibangun dua bagian sistem, yaitu GUI (Graphic user Interface) interface untuk administrasi poin SKKM, dan backend microservice. Backend microservice menyediakan API, lalu GUI akan berinteraksi dengan API dari microservice untuk melakukan administrasi atau transfer poin SKKM. Sistem SKKM didesain dengan awalnya setiap user (mahasiswa) hanya memiliki 0 SKKM poin, yang nantinya akan bertambah setiap kali mendapatkan SKKM.
Admin SKKM awalnya akan disediakan token blockchain sebagai entitas yang menjadi poin SKKM sejumlah sepuluh miliar. GUI interface sendiri akan dibagi menjadi dua jenis, yaitu GUI interface untuk bagian admin dan GUI interface untuk bagian user. GUI interface untuk bagian admin dibagi kembali menjadi beberapa bagian, yaitu interface untuk mentransfer poin SKKM kepada user dengan username, dan menu untuk mengonfirmasi validitas pengajuan SKKM.
d. Implementasi
Implementasi pada software engineering akan dibangun dengan sistem microservice, menggunakan framework Spring Boot yang menggunakan bahasa pemrograman Java versi 13 dan framework NodeJS (versi 12.16.1) yang menggunakan bahasa pemrograman Javascript. Selain framework yang
13 digunakan implementasi untuk melakukan integrasi dengan blockchain EOS (versi 2.0), dibutuhkan juga keosd dan nodeos. Keosd digunakan sebagai server untuk melakukan administrasi wallet EOS. Sedangkan nodeos, digunakan untuk administrasi yang berhubungan dengan transaksi dan blockchain.
e. Evaluasi
Tahap evaluasi, performa microservice akan dianalisis dan diuji coba dengan menggunakan dua komputer. Komputer satu digunakan untuk menjalankan instance server microservice, server untuk menjalankan service blockchain nodeos, dan server untuk menjalankan service wallet EOS, yaitu keosd. Komputer dua digunakan untuk menjalankan alat pengujian performa apache Jmeter.
3.2 Perancangan Aplikasi Blockchain
Solusi yang dirancang untuk dapat memenuhi atau memberikan solusi permasalahan SKKM yang ada pada SKKM UMN (Universitas Multimedia Nusantara), Blockchain EOS didesain dengan membuat token yang digunakan untuk melakukan transaksi poin SKKM dengan desain sebagai berikut:
1. Token yang dibuat akan memiliki jumlah sepuluh miliar token pada awalnya dan diberikan langsung kepada akun admin. Setiap akun memiliki token wallet masing masing. Wallet yang digunakan adalah wallet standar yang berada pada system wallet EOS yaitu keosd. Setiap pertama kali akun untuk mahasiswa dibuat, token SKKM akan mulai dari nol. User yang melakukan
14 request SKKM kepada admin dan jika diterima token SKKM akan dikirim ke wallet mahasiswa dengan jumlah satu SKKM.
2. Setiap transaksi token pada sistem nodeos akan menghasilkan id dari transaksi. Id dapat digunakan untuk melakukan tracing dari setiap transaksi yang dilakukan. Transaksi pada sistem service EOS, termasuk transfer token, setelah memasukkan jumlah nominal juga harus memasukkan memo. Pada penelitian ini, memo diisi dengan jenis SKKM saat transfer token dilakukan.
3. Setiap transaksi Id dari transaksi akan disimpan ke sebuah basis data. Artinya , setiap transaksi token antar user yang dilakukan, transaksi akan tersimpan pada sebuah basis data yang berisi data riwayat transaksi. Data riwayat transaksi tidak dapat dimanipulasi begitu saja karena data riwayat transaksi dapat dibandingkan dengan data yang ada pada blockchain EOS. Blockchain bersifat immutable, artinya setiap ada manipulasi data terdapat basis data, data berpotensi rusak yang mengakibatkan kesalahan data pada user.
3.3 Perancangan Frontend Aplikasi
Selain perancangan backend, dilakukan juga perancangan untuk antarmuka untuk memudahkan akses secara enduser. Rancangan dirancang untuk memenuhi kebutuhan administrasi SKKM dari sisi admin dan mahasiswa. Berdasarkan dari requirement untuk mengimplementasi SKKM Poin UMN dapat dibentuk rancangan desain untuk frontend atau tampilan aplikasi sebagai berikut.
Rancangan aplikasi dimulai dari register, user akan diminta memasukkan data pribadi mulai dari email, password, username EOS, dan nim. Button untuk
15 register di klik jika user telah memasukkan data pada semua kolom yang tersedia seperti pada (Gambar 3.1).
Gambar 3.1 Rancangan antarmuka register user
Gambar 3.2Rancangan antarmuka login user
Setelah user selesai melakukan registrasi, user akan diarahkan ke halaman login (Gambar 3.2). Antarmuka login terdiri dari kolom email dan password sebagai credential pribadi user. Jika tombol login ditekan end user akan berpindah ke halaman home. Jika yang dimasukkan adalah data kredensial mahasiswa, maka
16 akan masuk ke halaman home user. Jika yang dimasukkan adalah data kredensial admin, maka akan masuk ke halaman home admin.
Gambar 3.3 Halaman home user
Antarmuka home user akan menampilkan data user dan detail SKKM yang telah dikumpulkan (Gambar 3.3). Selain itu antarmuka home user juga menampilkan riwayat poin SKKM. Riwayat poin SKKM berisi SKKM yang sudah masuk SKKM ke user. Riwayat poin SKKM menampilkan data kegiatan yang dilakukan dan poin SKKM yang didapat.
17 Gambar 3.4 Halaman pengajuan user
Antarmuka halaman pengajuan user (Gambar 3.4) mahasiswa dapat mengisi kegiatan yang diikutinya untuk mendapatkan SKKM Poin. User juga harus mengisi kolom SKKM yang akan diajukan. Kolom SKKM yang tersedia pada antarmuka, dapat mengurangi kesalahan yaitu admin SKKM tidak mengetahui jelas kegiatan yang diikuti mahasiswa sesuai dengan reward SKKM yang didapat. Mahasiswa juga harus mengunggah bukti kegiatan yang diikuti. Jika user atau mahasiswa telah mengisi semua kolom yang dibutuhkan untuk pengajuan SKKM, tombol pengajuan akan mengirim data ke admin untuk nantinya dilakukan review.
18 Gambar 3.5Rancangan antarmuka pending request
Antarmuka pending request dapat memberikan informasi kepada user atau mahasiswa tentang status pengajuan SKKM (Gambar 3.5). Jika mahasiswa masih dapat melakukan edit data pengajuan maka pengajuan SKKM belum dilakukan review oleh admin. Jika sudah berstatus rejected atau ditolak maka data pengajuan sudah tidak dapat di edit. Jika sudah diterima oleh admin maka akan masuk ke bagian history user, dan jika sudah diterima maka data pengajuan SKKM telah hilang dari halaman pending request.
19 Gambar 3.6 Edit SKKKM user
User dapat melakukan edit pada jenis kegiatan, jenis SKKM, dan foto bukti. Selama admin belum melakukan proses review, pengajuan SKKM user dapat melakukan edit pada semua data yang di-input dalam proses pengajuan. Jika tombol edit ditekan dan berhasil maka user akan diarahkan kembali ke halaman pending request (Gambar 3.6).
Gambar 3.7 Antarmuka home admin
Antarmuka admin home berisi tampilan untuk mengirim SKKM secara satuan. Pada antarmuka admin home terdapat kolom untuk email yang akan dikirim
20 dan SKKM yang akan dikirim. Jika tombol untuk mengirim ditekan, SKKM akan langsung dikirim ke akun user yang dituju (Gambar 3.7).
Gambar 3.8 Antarmuka list pengajuan SKKM mahasiswa
Antarmuka list pengajuan mahasiswa akan list dari pengajuan yang diajukan oleh mahasiswa. Detail dari list akan berisi email, NIM (Nomor Induk Mahasiswa), tanggal pengajuan, dan SKKM yang diajukan. Pada bagian detail ada tombol untuk melihat detail dari pengajuan SKKM. Jika tombol detail ditekan maka admin akan diarahkan ke halaman detail pengajuan (Gambar 3.8).
21 Pada halaman detail pengajuan berisi detail SKKM yang di diajukan oleh user atau mahasiswa (Gambar 3.9). Admin dapat melihat jenis kegiatan yang dilakukan, jenis SKKM yang diajukan dan bukti yang di unggah oleh mahasiswa. Pada halaman antarmuka detail pengajuan terdapat dua tombol, yaitu terima dan tolak. Jika tombol terima ditekan maka secara otomatis SKKM di transfer kepada pihak yang mengajukan. Jika tombol tolak ditekan maka poin tidak akan terkirim kepada pihak yang mengajukan.
3.4 Perancangan Backend Aplikasi
Bagian backend terdiri dari dua bagian, yaitu bagian perancangan microservice yang digunakan untuk membuat akun yang menggunakan bahasa pemrograman Javascript dengan paradigma procedural, sehingga perancangan dilakukan dengan menggunakan flowchart. Microservice berikutnya menggunakan bahasa pemrograman Java yang memiliki paradigma object oriented atau berorientasi objek. Perancangan microservice dengan bahasa pemrograman Java digambarkan menggunakan use case diagram, class diagram, sequence diagram, dan activity diagram.
22 Gambar 3.10 Web service model microservice Javascript dan Java
23 Gambar 3.11 Use case diagram sistem microservice Java
24 Gambar 3.12 Diagram class microservice Java
25 Perancangan backend microservice, akan dirancang sesuai dengan model web service model yang dibangun menggunakan framework spring boot. Controller akan memiliki dependency ke service, service dapat memiliki dependency ke inbound/outbound service lain maupun repository service yang digunakan untuk mengambil data dari basis data. Basis data juga digunakan dalam membangun sistem backend dalam penelitian ini. Basis data yang digunakan akan berbasis NoSQL (non relational data base). Basis data NoSQL yang digunakan adalah mongoDB. Akses basis data hanya akan bisa diakses oleh sistem backend.
Perancangan dimulai dari user memasuki halaman utama pada sistem frontend. user yang masuk ke halaman utama sistem frontend, user akan dapat melakukan login maupun register. Saat tombol login ditekan oleh user pada bagian frontend, sistem frontend akan mengirim request data ke backend (Gambar 3.14 dan Gambar 3.16). Data yang dikirim oleh frontend akan diterima pada sistem backend. Sistem backend akan melakukan check jika data login credential user yang dikirim user apakah terdapat pada basis data sistem backend. Jika data credential user tidak ditemukan, maka sistem backend akan melakukan set error data user tidak ditemukan (Gambar 3.5).
User yang belum memiliki credential maka user dapat menekan tombol untuk melakukan register. User yang menekan tombol register, akan mengirim request data ke sistem backend. Sebelum dimasukkan pada basis data, akan dilakukan pengecekan dulu apakah ada data email yang duplikat (Gambar 3.15 dan Gambar 3.17). Setelah pengecekan duplikasi data dilakukan, data credential baru user yang diterima akan diteruskan untuk membuat username EOS pada wallet local EOS.
26 Jika pembuatan wallet EOS pada backend sistem berhasil, data user akan dimasukkan ke basis data. User akan menerima email dengan menggunakan sistem email SMTP (Simple Mail Protocol System) milik google untuk mengirim email ke user. Email yang diterima user akan mengarahkan menujun sistem frontend untuk melakukan verifikasi akun. user yang melakukan klik untuk menuju sistem frontend. Sistem frontend akan mengirim request yang berisi suatu kode token untuk verifikasi akun menuju sistem backend. Sistem backend akan melakukan update data akun user yang melakukan verifikasi.
Gambar 3.13 Diagram sequence login
27 Gambar 3.15 Diagram activity login
28 Gambar 3.16 Diagram activity register
29 Rancangan backend untuk user melakukan request SKKM dimulai dari user memasuki halaman request user SKKM. User terlebih dahulu harus mengisi data yang diperlukan untuk melakukan request SKKM pada sistem frontend. Setelah mengisi data sistem frontend akan mengirim data request SKKM ke sistem backend. Data yang dikirim akan langsung disimpan ke basis data oleh sistem backend (Gambar 3.18 dan Gambar 3.19).
30 Gambar 3.18 Diagram activity request SKKM points
31 User yang menuju halaman home user yang berisi data detail SKKM dan user(Gambar 3.20 dan Gambar 3.26) dapat melihat data tentang profil (Gambar 3.21 dan Gambar 3.27), detail requirement SKKM (Gambar 3.22 dan Gambar 3.28), dan riwayat transaksi SKKM (Gambar 3.23 dan Gambar 3.29). Data profil akan didapat dari data login yang dikirim dari backend menuju sistem frontend. Untuk memunculkan data detail requirement SKKM, sistem frontend akan mengirim request untuk mendapatkan detail requirement SKKM. Detail requirement berisi data SKKM yang sudah didapatkan oleh user, misalkan user sudah mendapatkan dua SKKM ilmiah dan penalaran, untuk dapat memenuhi requirement dibutuhkan minimal adalah enam. Sistem backend akan mendapatkan data detail requirement SKKM dari basis data riwayat transaksi SKKM. Basis data riwayat SKKM akan diolah pada sistem backend untuk mendapatkan hasil yang sesuai yang dibutuhkan oleh detail requirement SKKM.
User dapat melihat riwayat transaksi SKKM yang dilakukan oleh user. Sistem frontend akan melakukan request ke sistem backend untuk mendapatkan riwayat transaksi. Riwayat transaksi diambil dari basis data oleh sistem backend. Dalam penelitian ini dirancang juga fitur untuk user melihat status dari pengajuan SKKM. SKKM yang diajukan oleh user dapat diedit jika belum disetujui atau ditolak oleh admin. Jika user melakukan klik pada data list SKKM status (Gambar 3.24 dan Gambar 3.30) yang belum disetujui maka akan terbuka halaman detail yang datanya berasal dari request yang dikirim oleh sistem frontend ke sistem backend. Halaman detail request SKKM, dapat melakukan edit data request (Gambar 3.25 dan Gambar 3.31) yang dikirim oleh user. Jika data sudah selesai di
32 modifikasi oleh user, sistem frontend akan mengirim request berupa data yang sudah di update ke sistem backend untuk dilakukan modifikasi atau update pada basis data yang telah tersimpan. Data pengajuan SKKM yang ditolak oleh admin, tidak dapat dilakukan modifikasi atau edit.
Gambar 3.19 Diagram sequence user memasuki halaman SKKM detail page
33 Gambar 3.21 Diagram sequence user mendapatkan detil SKKM requirement
Gambar 3.22 Diagram sequence user mengambil data transaction history
34 Gambar 3.24 Diagram sequence user edit data SKKM
Gambar 3.25Diagram activity user mengambil data profil user
35 Gambar 3.27 Diagram activity user mendapatkan detail SKKM requirement
36 Gambar 3.28 Diagram activity user mengambil data transaction history
37 Gambar 3.29 Diagram activity user mengambil data SKKM status dari sistem
38 Gambar 3.30 Diagram activity user edit data SKKM
39 Admin dapat melakukan pengiriman SKKM langsung (Gambar 3.32 dan Gambar 3.33). Sistem frontend yang digunakan untuk melakukan pengiriman SKKM, berasal dari halaman home milik admin. Sistem frontend akan mengirim data user yang dimasukkan oleh admin untuk dikirimkan SKKM ke sistem backend. Sistem backend akan mengirim data ke sistem nodeos yang dimiliki oleh sistem blockchain EOS untuk melakukan transfer SKKM dari email yang dimasukkan admin. Email yang di input oleh admin akan dicari username pada wallet EOS pada basis data. Tiap transaksi yang dikirim ke sistem nodeos pada blockchain EOS akan tercatat pada basis data riwayat transaksi SKKM.
40 Gambar 3.32Diagram activity send SKKM with email
41 Admin juga dapat melihat seluruh pengajuan oleh user (mahasiswa). Sistem frontend melakukan request data seluruh pengajuan SKKM yang dilakukan oleh mahasiswa ke sistem backend. Sistem backend akan melakukan mengambil data dari basis data antrean pengajuan SKKM. Data pada list pengajuan SKKM akan terdiri dari data pengajuan SKKM yang belum dilakukan pemeriksaan oleh admin, data yang telah disetujui oleh admin, dan juga data yang ditolak oleh admin. Pemeriksaan terhadap pengajuan SKKM yang belum dilakukan pemeriksaan, admin harus terlebih dahulu melihat detail dari SKKM yang diajukan.
Pada tampilan dari sisi frontend (Gambar 3.8), user harus terlebih dahulu menekan tombol untuk melihat detail dari SKKM. Saat melihat detail pengajuan SKKM sistem frontend akan mengirim request ke sistem backend untuk mendapat data yang berisi detail pengajuan SKKM. Jika admin telah menyetujui atau menolak pengajuan SKKM, sistem frontend akan mengirim request ke sistem backend agar data yang telah disetujui ter-update. Sistem backend akan melakukan update data antrean SKKM yang tersimpan pada basis data. Data pengajuan SKKM yang telah diterima atau ditolak oleh admin tidak dapat dilakukan perubahan kembali.
42 Gambar 3.33 Diagram sequence admin get SKKM request
43 Gambar 3.35 Diagram activity admin get SKKM request
44 Gambar 3.36 Diagram activity admin menerima atau menolak SKKM
45 Rancangan sistem backend untuk fungsi create account, memiliki satu microservice yang berbeda untuk melakukan proses create account pada blockchain EOS. Microservice untuk create account dibangun menggunakan framework ExpressJS dengan bahasa pemrograman Javascript. Dikarenakan javascript bukan bahasa yang berorientasi objek maka visualisasi desain tidak menggunakan class diagram. Alur program dimulai dari menerima request create account dari microservice spring boot. Jika ada akun EOS yang duplikat, service EOS (nodeos) akan menolak. Alur program create account adalah sebagai berikut:
46 3.5 Perancangan Basis data
Sistem web service memiliki basis data untuk menyimpan data dari user yang dapat diintegrasi dengan web service yang sudah ada, data transaksi dari blockchain, dan data untuk menyimpan antrean request SKKM yang dikirim oleh user atau mahasiswa. Sistem basis data yang digunakan berbasis NoSQL (atau basis data non relasional). Basis data NoSQL yang digunakan adalah MongoDB. BerbedaBerbeda dengan basis data relasional, basis data NoSQL berbasis koleksi yang berisi dokumen dalam bentuk JSON atau Javascript Object Notation.
Basis data NoSQL dipilih dalam desain web service karena NoSQL sangat mudah beradaptasi dengan perubahan data yang dinamis sesuai kebutuhan. Selain itu sistem web service di desain untuk dapat diterapkan dengan sistem yang telah berjalan sekarang, karena sistem yang telah berjalan belum diketahui strukturnya seperti apa, sehingga basis data NoSQL cocok untuk kondisi kebutuhan sistem ini. Koleksi user memiliki dokumen yang terdiri dari field id, user email, eos username, password, NIM, token, is verified, createdDate, dan version. Field id merupakan field dasar dari setiap basis data. Koleksi user juga memiliki credential dan identitas user (user email, eos username, password, nim). Token merupakan field yang berfungsi untuk verifikasi user. Setiap melakukan pendaftaran user akan dikirim email verifikasi, token akan dikirimkan user untuk melakukan verifikasi. Sedangkan field isVerified, akan memberi tanda apakah user sudah melakukan verifikasi atau belum. Field id, createdDate, version akan dimiliki oleh semua koleksi pada basis data sistem web service yang dilakukan di penelitian ini. Created Date meruapakan field yang digunakan untuk mengetahui kapan dokumen dibuat,
47 dan version digunakan sebagai acuan versi data. Versi data digunakan jika ada perubahan pada field di database versi akan berubah sesuai perubahan yang dilakukan. Desain NoSQL pada basis data dalam sistem web service dalam penelitian:
Gambar 3.38 Desain basis data NoSQL user, SKKM Queue, SKKM Transaction History
Koleksi SKKM Queue memiliki dokumen yang terdiri field id, activity, photos, SKKM Points, email, nim, created date, version, is accepted. Field pada activity digunakan untuk menyimpan aktivitas yang dilakukan oleh mahasiswa agar mendapat poin SKKM. Field photos diisi dengan foto yang di-encode dengan Base64 encoding. Foto digunakan sebagai bukti mahasiswa benar benar
48 menjalankan aktivitas yang dilakukan. Field SKKM Points digunakan untuk menyimpan pengajuan SKKM yang diajukan oleh mahasiswa. Email dan nim merupakan field untuk menyimpan identitas pengajuan. Field isAccepted digunakan untuk mengetahui status pengajuan, keputusan admin untuk menerima dan menolak pengajuan SKKM yang diajukan mahasiswa. Koleksi SKKM Transaction History memiliki field yang terdiri dari id, transaction id, SKKM Points, email, activity, eos username, created date, version. Transaction Id digunakan untuk menyimpan id transaksi dari blockchain EOS.
