Tugas Pertemuan 4 PPL
Nama : Frederick Yonatan Susanto
NRP : 5025211121
Kelas : PPL A
Tahun Ajaran : 2023/2024 (Genap)
Pada pertemuan keempat di kelas PPL A, kita diminta untuk mengamati/mencari informasi sebuah aplikasi kemudian menggambarkan bagaimana bentuk arsitekturnya dan menjelaskan tugas serta tanggung jawab dari setiap komponen dalam arsitektur tersebut. Referensi dapat dicari dari paperwork, jurnal, maupun dokumentasi aplikasi.
Referensi yang saya ambil yaitu "IMPLEMENTASI ARSITEKTUR MICROSERVICES PADA APLIKASI POINT OF SALE TOKO FLYOVER STIKER".
Software Architecture
Teknologi terus berkembang, memudahkan pengembangan aplikasi seperti Point of Sale (POS) yang membantu dalam pencatatan transaksi penjualan, kontrol persediaan, dan monitoring laporan penjualan. Pengembangan aplikasi umumnya menggunakan arsitektur monolitik untuk aplikasi kecil, tetapi ini sulit diterapkan pada skala besar. Arsitektur microservices menjadi solusi dengan membagi layanan besar menjadi layanan kecil. Sebuah penelitian mengimplementasikan arsitektur microservices pada aplikasi POS untuk toko "Flyover Stiker" dengan menggunakan tahapan Systems Development Life Cycle (SDLC). Aplikasi ini terbagi menjadi 6 layanan dan telah diuji dengan framework Cypress.
A. Arsitektur Sistem
1. Arsitektur Microservis
Metode penelitian yang digunakan dalam pembuatan aplikasi Point of sale dengan arsitektur microservices menggunakan SDLC (Software Development Life Cycle).
Berikut merupakan rancangan model arsitektur microservices yang dibuat dengan membagi layanan menjadi 6 yaitu layanan API-gateway, user, produk, order, payment, dan kurir.
Gambar 1. Model Arsitektur Microservices
Gambar 1 merupakan rancangan model
Arsitektur Microservices untuk aplikasi
POS. Setiap permintaan (request) yang
dilakukan dari aplikasi Front-end merujuk
pada layanan (service) yang bernama API
Gateway. API Gateway berfungsi sebagai
perantara antara request dari aplikasi frontend ke service - service yang dipanggil
oleh user dari aplikasi front-end.
Komunikasi antara aplikasi Front end, API
gateway dan service - service lainnya
dalam Arsitektur Microservices
menggunakan Rest (Representational
State Transfer) merupakan bentuk
komunikasi antar web service melalui
HTTP (Hypertext Transfer Protocol).
- Microservices
Microservices
Microservices atau disebut arsitektur
microservices merupakan gaya arsitektur
untuk pengembangan aplikasi dengan
membagi layanan (services) besar menjadi
service - service kecil. Tujuan utama
penggunaan arsitektur microservice
adalah memecahkan layanan yang
kompleks menjadi lebih kecil dan sederhana untuk tujuan fungsionalitas
umum. Setiap service yang pisahkan harus
lebih sederhana atau kecil bertujuan untuk
memudahkan dalaman maintenance,
develop, tested dan mudah di scale
(Resende D & Osman P,. 2019).
Beberapa hal yang harus diperhatikan
dalam pembuatan aplikasi dengan
arsitektur microservice yaitu:
1. Ketergantungan (Dependencies)
Arsitektur microservices adalah teknologi
agnostic, ketergantungan berbeda untuk
setiap layanan yang berbeda mungkin
muncul.
2. Kompleksitas (Complexity)
Aplikasi yang kecil, kompleksitas bootstrap
lebih besar dibandingkan dengan
monolitik
3. Pengujian (End to end testing)
Menjadi lebih kompleks untuk pengujian
end to end test, karena jumlah service
untuk saling terhubung pasti lebih besar
dari pada aplikasi dengan arsitektur
monolitik.
- Software Development Life Cycle (SDLC)
SDLC adalah metode pengembangan
aplikasi yang umum digunakan dalam
membangun atau mengembangkan sistem
informasi. Rekayasa perangkat lunak,
konsep SDLC mendasari berbagai jenis
metodologi pengembangan perangkat
lunak. Metodologi-metodologi ini
membentuk suatu kerangka kerja untuk
perencanaan dan pengendalian
pembuatan sistem informasi, yaitu proses
pengembangan perangkat lunak (Susanto,
R dan Andriana, A, 2016). Terdapat
beberapa model dalam pengembangan
dengan metode SDLC yaitu waterfall,
prototype, interative, rapid application
development dan lainnya.
Tahapan dalam
pengembangan aplikasi menggunakan
metode SDLC dengan model waterfall
yaitu:
1. Analisis, terdiri dari analisis kebutuhan
fungsional dan non-fungsional.
2. Perancangan, melakukan pembuatan
rancangan sistem UML, baik dari alur
sistem, rancangan database dan
rancangan user interface.
3. Implementasi menggunakan koding
bahasa pemrograman Javascript
terhadap racangan sistem yang telah
dibuat sebelumnya.
4. Pengujian dilakukan pengujian end to
end terhadap sistem yang telah dibuat.
5. Pemeliharaan (maintenance)
melakukan perawatan dan monitoring
terhadap aplikasi yang telah berjalan.
B. Rancangan UML
Unified Modeling Language (UML)
Unified Modeling Language adalah sebuah
teknik pengembangan sistem yang
menggunakan bahasa grafis sebagai alat
untuk mendokumentasi dan melakukan
spesifikasi pada sistem (Mulyani S,. 2017).
UML adalah metode perancangan untuk
pengembangan sistem yang berorientasi
object dan juga sebagai alat pendukung
perancangan sistem. Terdapat beberapa
jenis diagram UML yang dapat digunakan
sebagai alat perancangan sistem antara
lain adalah Use Case Diagram, Activity
Diagram, Sequence Diagram dan Class
Diagram.
1. Use Case Diagram
Use case diagram terdiri dari use case untuk hak pengguna user dan admin. Berikut merupakan rancangan use case untuk hak pengguna user:
Gambar 1. Use Case Diagram User
Gambar 1 merupakan use case untuk hak
akses user, setelah user melakukan login /
daftar akun, user dapat melakukan
transaksi pemesanan produk pada
halaman utama. User dapat mengakses
dan melihat status data transksi yang telah
dilakukan sebelumnya. User juga dapat
melakukan pengubahan data profil seperti
data alamat, email dan password pada
halaman profil.
Berikut merupakan
rancangan use case untuk hak pengguna
admin:
Gambar 2. Use Case Diagram Admin
Gambar 2 merupakan use case untuk
pengguna dengan hak akses pengguna
admin. Admin dapat melakukan transaksi
pemesanan produk, jika user atau pembeli
melakukan transaksi secara langsung
(offline) pada toko dengan pilihan
pemesanan pada aplikasi adalah
pembayaran langsung. Admin dapat
melakukan manajemen produk dan
kategori untuk mengatur jumlah stok
barang dan jenis kategori barang pada
halaman produk. Admin dapat
memanajemen data pesanan yang
dilakukan oleh user secara online seperti
mengubah status pemesanan dan
menambahkan nomor resi pengiriman
pada halaman dashboard. Admin dapat
mengubah data alamat, email dan
password pada halaman profil.
2. Activity Diagram
Activity diagram menggambarkan
bagaimana alur aktivitas yang terjadi dalam
sistem, bagaimana tiap - tiap aktivitas
saling berinteraksi dengan aktivitas lain
dan sampai bagaimana berakhirnya suatu
aktivitas. Berikut merupakan activity untuk
proses order dan proses pembayaran:
Gambar 3. Activity Diagram Proses Order
Gambar 3 merupakan bentuk activity untuk
proses order. Setelah user login, pada
aplikasi ditampilkan halaman utama pada
halaman tersebut dilakukan request data
produk kepada backend microservices dan
ditampilkan pada aplikasi, lalu user dapat
memilih produk yang ingin dipesan.
Halaman checkout melakukan request ke
backend microservices untuk data produk,
user dan estimasi pengiriman lalu user
memilih jenis jasa pengiriman, konfirmasi
data yang dipesan dan backend
microservices memproses menyimpan
data order, setelah order berhasil dirahkan
pada halaman pembayaran dan activity
berakhir.
Berikut activity diagram proses pembayaran:
Gambar 4. Activity Diagram Proses Pembayaran
Gambar 4 merupakan bentuk activity untuk
pembayaran. Activity dimulai pada
halaman pembayaran dengan meminta
data order dari backend microservices lalu
user diminta untuk memilih metode
pembayaran. Opsi metode bayar terbagi
menjadi dua yaitu pembayaran secara
langsung dan melalui payment gateway,
jika memilih pembayaran langsung user
melakukan pembayaran melalui toko
secara offline yang diproses oleh admin dan jika metode pembayaran melalui
payment gateway user akan diarahkan ke
halaman form pembayaran lalu user pilih
jenis pembayaran, konfirmasi
pembayaran, dan backend microservices
secara otomatis melakukan update status
order setelah sukses ditampilkan halaman
detail order dan activity berakhir.
3. Sequence Diagram
Sequence diagram menggambarkan
bagaimana alur interaksi antara object
yang terjadi pada aplikasi secara dinamis.
Gambar 5. Sequence Diagram Order
Gambar 5 merupakan sequence diagram
untuk proses order. Pertama kali user
ditampilkan halaman produk / utama. User
diminta untuk memilih data produk yang
ingin dipesan, setelah memilih produk yang
dipesan, lalu bagian back end microservice
menyimpan data produk, setelah data
berhasil disimpan backend microservice
melakukan request data keranjang, user
dan kurir lalu user diarahkan pada
halaman checkout lalu user diminta untuk
memilih jasa pengiriman, setelah user
memilih jasa pengiriman lalu data order
disimpan oleh backend microservices,
setelah data order disimpan pada aplikasi
akan ditampilkan halaman pembayaran.
Gambar 6. Sequence Diagram Pembayaran
Gambar 6 merupakan proses pembayaran
dilakukan setelah user melakukan
pembuatan order pada halaman produk.
Petama kali user diminta untuk memilih
metode pembayaran, jenis metode
pembayaran yang disediakan yaitu
pembayaran secara langsung yang
dilakukan secara langsung pada toko dan
pembayaran secara online (payment
gateway).
Pilihan pembayaran secara langsung pada
backend microservice secara otomatis
melakukan penyimpanan data order dan
mengupdate status pemesanan dan jika
memilih pembayaran dengan payment
gateway user diminta memilih jenis
pembayaran yang disedikan oleh payment
gateway setelah memilih jenis pembayaran
secara otomatis back end microservice
mem-validasi pembayaran dan merubah
status pembayaran, lalu user diarahkan
pada halaman detail order.
4. Class Diagram
Class diagram microservices
menggambarkan bentuk interaksi antara
class yang saling berkaitan pada aplikasi
microservices.
Gambar 7. Class Diagram Microservices
Berdasarkan gambar 7. class diagram
terdapat tujuh class yang saling terhubung.
Class user memiliki atribut id_user,
nama_user, email, password dan
nomor_handphone, Class refresh_token
memiliki atribut yang tediri dari id_token,
user_id dan token, class alamat terdiri dari
atribut id_alamat, id_user, alamat_kirim
dan kodepos, class produk terdiri dari
id_produk, id_category, nama_produk,
gambar, harga dan stok, class category
terdiri dari id_categori dan nama_category,
class order terdiri dari id_order, id_user,
id_alamat, nomor_kurir, nomor_invoice,
biaya_pengiriman, estimasi_pengiriman,
destination_pengiriman, status_
pembayaran, metode_pembayaran dan
status. Class Order_item terdiri dari atribut
id_item, id_produk, id_order dan jumlah.
C. Implementasi
1. Halaman Login
Halaman Login merupakan halaman yang
ditampilkan sebelum pengguna atau admin
dapat masuk aplikasi.
Gambar 8. Halaman Login
Gambar 8 merupakan bentuk
output tampilan untuk halaman login dan
telah ditambahkan validasi untuk setiap
inputan pada form login.
2. Halaman Beranda
Halaman beranda ditampilkan setelah
pengguna melakukan login, pada halaman
beranda ditampilkan data produk dalam
bentuk komponen card dan terdapat
komponen keranjang yang berisi draft data
produk yang ingin dipesan.
Gambar 9. Halaman Beranda
Gambar 9 merupakan output untuk
tampilan halaman beranda, pada halaman
beranda ditampilkan data produk dan data
keranjang serta metode jenis
pembayarannya.
3. Halaman Pengiriman
Halaman pengiriman ditampilkan ketika
pengguna memilih menggunakan jasa
pengiriman (courier service) pada saat
melakukan order di halaman beranda.
Gambar 10. Halaman Pengiriman
Gambar 10 merupakan tampilan output
halaman pengiriman yang berisikan data
alamat pemesan, form untuk memilih jasa
kurir, data produk yang dipesan dan rincian
jumlah pembelian barang.
4. Halaman Form Pembayaran
Tampilan form pembayaran merupakan
tampilan yang disedakan oleh penyedia
layanan Payment Gateway yaitu Midtrans
yang digunakan untuk menangani
pembayaran secara online.
Gambar 11. Halaman Form Pembayaran
Gambar 11 form pembayaran berisikan list
metode pembayaran yaitu pembayaran
memalui e-wallet, transfer melalui bank
dan kartu kredit pada pengujian, metode
pembayaran yang digunakan adalah menggunakan transfer melalui bank dan
kartu kredit.
5. Halaman Dashboard
Halaman Dashboard berisi data laporan
pemesanan, stok produk dan jumlah
pendapatan bulanan.
Gambar 12. Halaman Dashboard
Gambar 12 halaman dashboard
ditampilkan komponen dalam bentuk card
yang berisi data total penjualan bulan,
jumlah produk, dan jumlah transaksi, serta
ditampilkan komponen table yang berisi
semua data order yang telah dibuat oleh
user dan terdapat komponen untuk
mengurutkan data order berdasarkan
nomor_invoice, status_order dan
tanggal_order.
D. Kesimpulan
Berdasarkan hasil analisis, perancangan,
implementasi dan pengujian yang telah
dilakukan, disimpulkan bawah
Implementasi Arsitektur Microservices
aplikasi POS (point of sale) pada toko
Flyover Sticker telah berhasil dilakukan.
Aplikasi Microservices dibagi menjadi dua
bagian yaitu aplikasi front end dan aplikasi
backend yang terdiri dari beberapa layanan
service yang telah dibagi menjadi 6 (enam)
buah layanan kecil.
Aplikasi Microservices telah diterapkan
keamanan untuk tiap service dengan
menerapkan sistem tokenisasi sebagai
autentikasi untuk mengakses suatu
service.
Testing dilakukan dengan metode end-toend testing secara otomatis (automated
testing) menggunakan framework testing
yaitu Cypress.
Pengujian yang dilakukan yaitu proses
login, registrasi, menampilkan halaman
utama, melakukan manajemen data
produk dan kategori, melakukan proses
transaksi, menampilkan pop-up snap
pembayaran payment gateway dari
midtrans, menampilkan data pengiriman
(shipment), menampilkan data
pemesanan, menampilkan detail data
pesanan, melakukan manajemen data
profil, menampilkan data laporan penjualan
dan melakukan proses logout.
Berdasarkan pengujian end-to-end yang
dilakukan, test case yang dibuat telah
berhasil memenuhi kebutuhan untuk setiap
test case yang dibuat pada setiap halaman
aplikasi.
.png)
Comments
Post a Comment