BAB 4. PERANCANGAN SISTEM Setelah melakukan proses analisa sistem maka akan dilakukan proses perancangan sistem yang diharapkan sesuai dengan kebutuhan pengguna yang dianalisa. Perancangan sistem ini menggunakan bahasa Unified Modeling Language sebagai bahasa pemodelan. Perancangan aplikasi ini menggunakan software utama sebagai berikut : 1. Netbeans IDE sebagai alat bantu utama pembuatan aplikasi CrondManager. 2. Pencil sebagai alat bantu untuk mengola UML. 3. Aksi IDE sebagai alat bantu untuk mengelola database yang mana aksi IDE ini sebagai database client. 4. MySQL Workbench alat bantu untuk membuat ERD. 4.1. Perancangan Algoritma Algoritma yang digunakan dalam aplikasi ini adalah algoritma Priority Scheduling dan algoritma Multithreading karena ketika proses yang sudah dijabarkan sesuai dengan tanggal berjalan nya berserta interval waktu nya maka setiap proses akan berjalan dengan urutan prioritas nya maka dari itu dibutuhkan algoritma Multithreading yang akan mengelolah proses runtime secara pararel yang berjalan pada algoritma Priority Scheduling yang mana proses tersebut berjalan secara sequencial. 4.1.1 Algoritma Priority Scheduling Priority Scheduling Merupakan algoritma yang mendahulukan proses yang memiliki prioritas tertinggi. Prioritas proses ditentukan berdasar: - Time limit - Memory requirement - File access - Perbandingan antara burst proses dengan CPU - Tingkat kepentinagn proses Priority scheduling dapat dijalankan secara preemptive dan non-preemptive - Preemptive : jika ada proses yang baru datang memiliki prioritas lebih tinggi dari proses yang sedang berjalan, maka proses yang sedang berjalan tsb dihentikan, lalu CPU dialihkan untuk proses yang baru datang tersebut.
- Non preemptive : proses yang baru datang tidak dapat menganggu proses yang sedang berjalan, tapi hanya diletakkan di depan queue. Kelemahan Priority Scheduling adalah terjadinya infinite blocking (starvation), yaitu suatu proses dengan prioritas yang rendah memiliki kemungkinan tidak pernah dieksekusi jika terdapat proses lain yang memiliki prioritas lebih tinggi. Solusi dari starvation adalah aging, yaitu meningkatkan prioritas dari setiap proses yang menunggu dalam queue secara bertahap. 4.1.2 Algoritma Multithreading Java merupakan salah satu bahasa yang telah mendukung pengembangan aplikasi multithreading (banyak thread). Thread dapat dianalogikan sebagai suatu sub-proses yang ada dalam proses. dengan menggunakan thread maka aplikasi yang dibangun dapat menjalankan banyak aktivitas secara konkuren. Multithreading memiliki keunggulan dibandingkan Multiprocessing yaitu sebagai berikut: 1. Thread lebih ringan dibandingkan dengan proses 2. Thread dapat berbagi data dan kode 3. Switching antar Thread jauh lebih hemat cpu dari pada process 4. Thread memungkinkan tugas yang berbeda yang akan dilakukan secara bersamaan Thread dalam java dapat diilustrasikan oleh gambar berikut: Gambar 4.1.2-1 Thread dalam Java. Secara umum siklus dari setiap thread dalam java adalah sebagai berikut:
Gambar 4.1.2 2 Siklus Thread. Terdapat 2 cara yang dapat digunakan untuk menciptakan thread dalam java,yaitu: - Dengan mengimplementasikan Runnable Interface (java.lang.runnable) - Dengan meng-extends kan Thread Class (java.lang.extends) 4.2. Perancangan Sistem Untuk memudahkan pembuatan aplikasi CrondManager, maka akan dibuat model menggunakan Unified Model Language (UML). Dengan menggunakan UML, akan dibuat diagram use case, activity, sequence. Diagram diagram ini akan membantu melihat interaksi yang terjadi di aplikasi. Dan dapat membantu melihat suatu permasalahan yang kompleks menjadi lebih sederhana. 4.2.1 Perancangan Basis Data Perancangan Database adalah proses untuk menentukan isi dan pengaturan data yang dibutuhkan untuk mendukung berbagai rancangan sistem. Tujuan Perancangan Database : 1. Untuk memenuhi informasi yang berisikan kebutuhan-kebutuhan user secara khusus dan aplikasi-aplikasinya. 2. Memudahkan pengertian struktur informasi. 3. Mendukung kebutuhan-kebutuhan pemrosesan dan beberapa obyek penampilan (response time, processing time, dan storage space).
Pembuatan aplikasi CrondManager ini menggunakan DBMS MySQL 5.6 dan hanya menggunakan satu schema database. Schema database tersebut memiliki beberapa tabel, Berikut tabel tabel yang digunakan beserta tipe data nya : 1. Tabel cronlist 2. Tabel cron_history Gambar 4.2.1. 1 Tabel cronlist. Gambar 4.2.1. 2 Tabel cron_history.
3. Tabel bank_inquiry 4. Tabel dkpr_inquiry Gambar 4.2.1. 3 Tabel bank_inquiry.
5. Tabel config_dkpr_area Gambar 4.2.1. 4 Tabel dkpr_inquiry. 6. Tabel mtr_agent Gambar 4.2.1. 5 Tabel config_dkpr_area. Gambar 4.2.1. 6 Tabel mtr_agent.
7. Tabel mtr_consumer 8. Tabel mtr_agent_updated Gambar 4.2.1. 7 Tabel mtr_consumer.
9. Tabel mtr_consumer_updated Gambar 4.2.1. 8 Tabel mtr_agent_updated. 10. Tabel bi_agent Gambar 4.2.1. 9 Tabel mtr_consumer_updated. Gambar 4.2.1. 10 Tabel bi_agent.
11. Tabel bi_consumer Gambar 4.2.1. 11 Tabel bi_consumer. 4.2.2 ERD Dari tabel tabel yang digunakan berikut schema ERD untuk aplikasi CrondManager : Gambar 4.2.2. 1 ERD CrondManager.
4.2.3 Enkripsi dan Dekripsi Data Berawal dari kebutuhan terkait keamanan data dari serangan oleh digital attacker seperti pencurian data data penting. Maka dari itu untuk meminimalisir dan mencegah terkait adanya masalah tersebut maka aplikasi CrondManager melakukan enkripsi pada nama task atau proses yang dijalankan. Dalam hal ini aplikasi CrondManager menerapkan ilmu kriptografi enkripsi/dekripsi. - Enkripsi adalah proses mengolah informasi/data (plaintext) menjadi bentuk hampir tidak dikenali (ciphertext) dengan menggunakan algoritma tertentu. - Dekripsi adalah kebalikan dari enkripsi yaitu mengubah kembali ciphertext menjadi plaintext. Gambar 4.2.3 1 Basic Algoritma Enkripsi/Dekripsi Gambar 4.2.3 2 Data table cronlist enkripsi
Gambar 4.2.3 3 Dekripsi pada aplikasi
4.2.4 Use Case Diagram Diagram ini menggambarkan interaksi antar aktor atau pengguna dengan sistem atau aplikasi. User case diagram untuk aplikasi CrondManager dengan menggunakan Java Native dan Database MySQL dapat dilihat dari gambar berikut : Gambar 4.2.3. 1 Use Case Diagram. Berikut adalah keterangan mengenai use case diagram diatas : Nama Use Case Keterangan Login Server Pada user case ini, system administrator akan melakukan login ke server aplikasi crondmanager untuk melihat task yang aktif dan melakukan konfigurasi email. BankInquiry Pada use case ini, aplikasi akan mengolah data dari tabel inquiry aplikasi ke tabel Bank Inquiry agar dapat diolah oleh Business Intelligent (Transform Data). MasterCustomer Pada use case ini, aplikasi akan mengolah data dari tabel agent aplikasi ke tabel
customer yang diolah Business Intelligent (Transform Data). MasterConsumer Pada use case ini, aplikasi akan mengolah data dari tabel consumer aplikasi ke tabel consumer yang diolah Business Intelligent (Transform Data). Config Email Pada use case ini, system administrator akan melakukan konfigurasi email yang ada di aplikasi. Send Email Use case in merupakan extends turunan dari use case Config Email, yang mana merupakan proses pengiriman ke user Business Intelligent. AlertNotifyCustomer Pada use case ini, aplikasi akan mengirimkan notifikasi berupa email ke customer yang ada pada list query email yang dibuat. CustomerLog Pada use case ini, aplikasi akan melakukan backup/pemindahan data dari tabel utama agent ke tabel backup agent. ConsumerLog Pada use case ini, aplikasi akan melakukan backup/pemindahan data dari tabel utama agent ke tabel backup agent. CoreUser Pada use case ini, aplikasi akan mengolah data dari database MySQL ke dalam bentuk JSON dan di store pada server ElasticSearch dalam bentuk text document JSON. FeaturedCustomer Pada use case ini, aplikasi akan mengolah data dari database MySQL ke dalam bentuk dan di store pada server Redis data on RAM dalam bentuk JSON.
CustomerModify ConsumerModify Pada use case ini, aplikasi akan melakukan manipulasi data agent pada field status secara otomatis dengan periode yang sudah ditentukan. Pada use case ini, aplikasi akan melakukan manipulasi data consumer pada field status secara otomatis dengan periode yang sudah ditentukan. Tabel 4.2.3. 1 Keterangan Use Case Diagram. 4.2.5 Activity Diagram Activity diagram menggambarkan berbagai alur aktivitas dalam suatu sistem yang sedang berlangsung. Activity diagram dapat membantu menjelaskan diagram use case Dengan lebih mendalam sehingga mempermudah proses pembuatan aplikasi. Berikut merupakan Activity diagram yang menjalaskan interaksi antara pengguna atau aktor dengan aplikasi CrondManager menggunakan Java Native dan Database MySQL. Aktivitas dimulai ketika system melakukan sinkronisasi tanggal server dengan tanggal proses masing masing task yang dikelompokan sesuai penggunanya atau aktor. 1. Activity Diagram Login Server Keterangan : Gambar 4.2.4. 1 Activity Diagram Login Server.
Aktivitas diawali oleh System Administrator yang melakukan input username dan password ke server, yang selanjutnya server akan melakukan pengecekan otorisasi jika username dan password cocok maka akan masuk ke server dan apabila tidak cocok maka akan muncul pesan error. 2. Activity Diagram BankInquiry Gambar 4.2.4. 2 Activity Diagram Bank Inquiry. Keterangan : Aktivitas diawali oleh sistem yang melakukan pengecekan datetime server dengan datetime yang ada di database sistem. Jika sinkronisasi sesuai maka pemrosesan data Bank Inquiry berjalan. Jika tidak maka pemrosesan data Bank Inquiry tidak akan dilakukan dan hanya mengirim status sleep pada report yang dikirim ke user namun user dapat melakukan force proses jika diinginkan agar proses berjalan. Ketika pemrosesan data Bank Inquiry selesai maka akan mendapatkan hasil sukses dan gagal. Jika gagal makan akan mengirimkan notifikasi berupa email ke user dengan menampilkan penyebab data gagal diproses. Jika berhasil maka mengirimkan status sukses pada report yang di generate untuk user setiap hari nya.
3. Activity Diagram MasterCustomer Gambar 4.2.4. 3 Activity Diagram Master Customer. Keterangan: Aktivitas diawali oleh sistem yang melakukan pengecekan datetime server dengan datetime yang ada di database sistem. Jika sinkronisasi sesuai maka pemrosesan data Master Customer berjalan. Jika tidak maka pemrosesan data Master Customer tidak akan dilakukan dan hanya mengirim status sleep pada report yang dikirim ke user namun user dapat melakukan force proses jika diinginkan agar proses berjalan. Ketika pemrosesan data Master Customer selesai maka akan mendapatkan hasil sukses dan gagal. Jika gagal makan akan mengirimkan notifikasi berupa email ke user dengan menampilkan penyebab data gagal diproses. Jika berhasil maka mengirimkan status sukses pada report yang di generate untuk user setiap hari nya.
4. Activity Diagram MasterConsumer Gambar 4.2.4. 4 Activity Diagram Master Consumer. Keterangan: Aktivitas diawali oleh sistem yang melakukan pengecekan datetime server dengan datetime yang ada di database sistem. Jika sinkronisasi sesuai maka pemrosesan data Master Consumer berjalan. Jika tidak maka pemrosesan data Master Consumer tidak akan dilakukan dan hanya mengirim status sleep pada report yang dikirim ke user namun user dapat melakukan force proses jika diinginkan agar proses berjalan. Ketika pemrosesan data Master Consumer selesai maka akan mendapatkan hasil sukses dan gagal. Jika gagal makan akan mengirimkan notifikasi berupa email ke user dengan menampilkan penyebab data gagal diproses. Jika berhasil maka mengirimkan status sukses pada report yang di generate untuk user setiap hari nya.
5. Activity Diagram Config Email Gambar 4.2.4. 5 Activity Diagram Config Email Keterangan: Aktivitas diawali oleh System administartor yang melakukan Login ke server CrondManager. Setelah itu melakukan edit file konfigurasi yang ada pada folder conf, Kemudian menambahkan email yang ingin ditambahkan dan kemudian melakukan restart service CrondManager. CrondManager akan secara otomatis mengubah konfigurasi sesuai yang ada pada folder conf.
6. Activity Diagram AlertNotifyCustomer Gambar 4.2.4. 6 Activity Diagram Alert Notify customer. Keterangan: Aktivitas diawali oleh sistem yang melakukan pengecekan datetime server dengan datetime yang ada di database sistem. Jika sinkronisasi sesuai maka pemrosesan data Alert Notify Customer berjalan. Jika tidak maka pemrosesan data Alert Notify Customer tidak akan dilakukan dan hanya mengirim status sleep pada report yang dikirim ke user namun user dapat melakukan force proses jika diinginkan agar proses berjalan. Ketika pemrosesan data Alert Notify Customer selesai maka akan mendapatkan hasil sukses dan gagal. Jika gagal makan akan mengirimkan notifikasi berupa email ke user dengan menampilkan penyebab data gagal diproses. Jika berhasil maka mengirimkan report ke list user yang ada di database report yang dikirimkan berupa summary data yang dibentuk dalam format html email.
7. Activity Diagram CustomerLog Gambar 4.2.4. 7 Activity Diagram Customer Log. Keterangan: Aktivitas diawali oleh sistem yang melakukan pengecekan datetime server dengan datetime yang ada di database sistem. Jika sinkronisasi sesuai maka pemrosesan data Customer Log berjalan. Jika tidak maka pemrosesan data Customer Log tidak akan dilakukan dan hanya mengirim status sleep pada report yang dikirim ke user namun user dapat melakukan force proses jika diinginkan agar proses berjalan. Ketika pemrosesan data Customer Log selesai maka akan mendapatkan hasil sukses dan gagal. Jika gagal makan akan mengirimkan notifikasi berupa email ke user dengan menampilkan penyebab data gagal diproses. Jika berhasil maka proses backup data history Customer berjalan, proses backup data history ini dimulai membuat tabel dengan memiliki prefix tanggal setelah itu melakukan insert data ke tabel backup dengan prefix tanggal tersebut, kemudian melakukan penghapusan data pada tabel history.
8. Activity Diagram ConsumerLog Gambar 4.2.4. 8 Activity Diagram Consumer Log. Keterangan: Aktivitas diawali oleh sistem yang melakukan pengecekan datetime server dengan datetime yang ada di database sistem. Jika sinkronisasi sesuai maka pemrosesan data Consumer Log berjalan. Jika tidak maka pemrosesan data Consumer Log tidak akan dilakukan dan hanya mengirim status sleep pada report yang dikirim ke user namun user dapat melakukan force proses jika diinginkan agar proses berjalan. Ketika pemrosesan data Consumer Log selesai maka akan mendapatkan hasil sukses dan gagal. Jika gagal makan akan mengirimkan notifikasi berupa email ke user dengan menampilkan penyebab data gagal diproses. Jika berhasil maka proses backup data history Consumer berjalan, proses backup data history ini dimulai membuat tabel dengan memiliki prefix tanggal setelah itu melakukan insert data ke tabel backup dengan prefix tanggal tersebut, kemudian melakukan penghapusan data pada tabel history.
9. Activity Diagram CoreUser Gambar 4.2.4. 9 Activity Diagram Core User. Keterangan: Aktivitas diawali oleh sistem yang melakukan pengecekan datetime server dengan datetime yang ada di database sistem. Jika sinkronisasi sesuai maka pemrosesan data Core User berjalan. Jika tidak maka pemrosesan data Core User tidak akan dilakukan dan hanya mengirim status sleep pada report yang dikirim ke user namun user dapat melakukan force proses jika diinginkan agar proses berjalan. Ketika pemrosesan data Core User selesai maka akan mendapatkan hasil sukses dan gagal. Jika gagal makan akan mengirimkan notifikasi berupa email ke user dengan menampilkan penyebab data gagal diproses. Jika berhasil maka proses pembentukan file dalam format JSON untuk data Core User berjalan, proses pembentukan file dalam format JSON ini dimulai dari pengambilan data dari database, setelah data di format dalam bentuk JSON maka selanjutnya akan di store pada server ElasticSearch.
10. Activity Diagram FeaturedCustomer Gambar 4.2.4. 10 Activity Diagram Featured Customer. Keterangan: Aktivitas diawali oleh sistem yang melakukan pengecekan datetime server dengan datetime yang ada di database sistem. Jika sinkronisasi sesuai maka pemrosesan data Featured Customer berjalan. Jika tidak maka pemrosesan data Featured Customer tidak akan dilakukan dan hanya mengirim status sleep pada report yang dikirim ke user namun user dapat melakukan force proses jika diinginkan agar proses berjalan. Ketika pemrosesan data Featured Customer selesai maka akan mendapatkan hasil sukses dan gagal. Jika gagal makan akan mengirimkan notifikasi berupa email ke user dengan menampilkan penyebab data gagal diproses. Jika berhasil maka proses pembentukan file dalam format JSON untuk data Featured Customer berjalan, proses pembentukan file dalam format JSON ini dimulai dari pengambilan data dari database, setelah data di format dalam bentuk JSON maka selanjutnya akan di store pada Redis Server.
11. Activity Diagram CustomerModify Gambar 4.2.4. 11 Activity Diagram Customer Modify. Keterangan: Aktivitas diawali oleh sistem yang melakukan pengecekan datetime server dengan datetime yang ada di database sistem. Jika sinkronisasi sesuai maka pemrosesan data Customer Modify berjalan. Jika tidak maka pemrosesan data Customer Modify tidak akan dilakukan dan hanya mengirim status sleep pada report yang dikirim ke user namun user dapat melakukan force proses jika diinginkan agar proses berjalan. Ketika pemrosesan data Customer Modify selesai maka akan mendapatkan hasil sukses dan gagal. Jika gagal makan akan mengirimkan notifikasi berupa email ke user dengan menampilkan penyebab data gagal diproses. Jika berhasil maka proses update status Consumer berjalan, proses update terhadap status Customer pada tabel dilakukan secara otomatis.
12. Activity Diagram ConsumerModify Gambar 4.2.4. 12 Activity Diagram Consumer Modify. Keterangan: Aktivitas diawali oleh sistem yang melakukan pengecekan datetime server dengan datetime yang ada di database sistem. Jika sinkronisasi sesuai maka pemrosesan data Consumer Modify berjalan. Jika tidak maka pemrosesan data Consumer Modify tidak akan dilakukan dan hanya mengirim status sleep pada report yang dikirim ke user namun user dapat melakukan force proses jika diinginkan agar proses berjalan. Ketika pemrosesan data Consumer Modify selesai maka akan mendapatkan hasil sukses dan gagal. Jika gagal makan akan mengirimkan notifikasi berupa email ke user dengan menampilkan penyebab data gagal diproses. Jika berhasil maka proses update status Consumer berjalan, proses update terhadap status Consumer pada tabel dilakukan secara otomatis.
4.2.6 Sequence Diagram Sequence diagram digunakan untuk menunjukkan bagaimana perilaku pada sebuah scenario. Diagram ini menunjukan interaksi antar class pada setiap use case. 1. Sequence Diagram Login Server Gambar 4.2.5. 1 Sequence Diagram Login Server. Deskripsi diagram sequence a. User mulai melakukan input username dan password. b. Jika username dan password cocok maka akan masuk ke server. c. Jika username dan password tidak cocok maka sistem akan memunculkan pesan error ke user.
2. Sequence Diagram BankInquiry Gambar 4.2.5. 2 Sequence Diagram Bamk Inquiry. Deskripsi diagram sequence d. Sistem mulai melakukan pengecekan datetime. e. Jika datetime cocok maka proses Bank Inquiry berjalan. f. Jika datetime tidak cocok maka sistem akan mengirimkan result sleep dan mengirimkan notify ke user. g. Setelah user menerima notify maka user dapat melakukan force proses Bank Inquiry. h. Jika datetime cocok atau user melakukan force proses maka generate data Bank Inquiry berjalan. i. Sistem akan mengirimkan notify terkait proses Bank Inquiry berupa result sukses maupun gagal ke user.
3. Sequence Diagram MasterCustomer Gambar 4.2.5. 3 Sequence Diagram Master Customer. Deskripsi diagram sequence a. Sistem mulai melakukan pengecekan datetime. b. Jika datetime cocok maka proses Master Customer berjalan. c. Jika datetime tidak cocok maka sistem akan mengirimkan result sleep dan mengirimkan notify ke user. d. Setelah user menerima notify maka user dapat melakukan force proses Master Customer. e. Jika datetime cocok atau user melakukan force proses maka generate data Master Customer berjalan. f. Sistem akan mengirimkan notify terkait proses Master Customer berupa result sukses maupun gagal ke user.
4. Sequence Diagram MasterConsumer Gambar 4.2.5. 4 Sequence Diagram Master Consumer. Deskripsi diagram sequence a. Sistem mulai melakukan pengecekan datetime. b. Jika datetime cocok maka proses Master Consumer berjalan. c. Jika datetime tidak cocok maka sistem akan mengirimkan result sleep dan mengirimkan notify ke user. d. Setelah user menerima notify maka user dapat melakukan force proses Master Consumer. e. Jika datetime cocok atau user melakukan force proses maka generate data Master Consumer berjalan. f. Sistem akan mengirimkan notify terkait proses Master Consumer berupa result sukses maupun gagal ke user.
5. Sequence Diagram Config Email Gambar 4.2.5. 5 Sequence Diagram Config Email. Deskripsi diagram sequence a. User telah berhasil login ke server Crondmanager. b. User masuk ke folder conf pada aplikasi CrondManager. c. Setelah itu user melakukan perubahan atau penambahan email ke file konfigurasi app.conf. d. Setelah perubahan pada file app.conf telah dilakukan user akan melakukan restart service CrondManager. e. Kemudian service CrondManager akan melakukan load konfigurasi yang sudah dilakukan perubuahan.
6. Sequence Diagram AlertNotifyCustomer Gambar 4.2.5. 6 Sequence Diagram Alert Notify Customer. Deskripsi diagram sequence f. Sistem mulai melakukan pengecekan datetime. g. Jika datetime cocok maka proses Alert Notify Customer berjalan. h. Jika datetime tidak cocok maka sistem akan mengirimkan result sleep dan mengirimkan notify ke user. i. Setelah user menerima notify maka user dapat melakukan force proses Alert Notify Customer. j. Jika datetime cocok atau user melakukan force proses maka pengiriman email report ke customer berjalan. k. Sistem akan mengirimkan notify terkait proses Alert Notify Customer berupa result sukses maupun gagal ke user.
7. Sequence Diagram CustomerLog Gambar 4.2.5. 7 Sequence Diagram Customer Log. Deskripsi diagram sequence a. Sistem mulai melakukan pengecekan datetime. b. Jika datetime cocok maka proses Customer Log berjalan. c. Jika datetime tidak cocok maka sistem akan mengirimkan result sleep dan mengirimkan notify ke user. d. Setelah user menerima notify maka user dapat melakukan force proses Customer Log. e. Jika datetime cocok atau user melakukan force proses maka backup data history customer berjalan. f. Sistem akan mengirimkan notify terkait proses Customer Log berupa result sukses maupun gagal ke user.
8. Sequence Diagram ConsumerLog Gambar 4.2.5. 8 Sequence Diagram Consumer Log. Deskripsi diagram sequence a. Sistem mulai melakukan pengecekan datetime. b. Jika datetime cocok maka proses Consumer Log berjalan. c. Jika datetime tidak cocok maka sistem akan mengirimkan result sleep dan mengirimkan notify ke user. d. Setelah user menerima notify maka user dapat melakukan force proses Consumer Log. e. Jika datetime cocok atau user melakukan force proses maka backup data history consumer berjalan. f. Sistem akan mengirimkan notify terkait proses Consumer Log berupa result sukses maupun gagal ke user.
9. Sequence Diagram CoreUser Gambar 4.2.5. 9 Sequence Diagram Core User. Deskripsi diagram sequence a. Sistem mulai melakukan pengecekan datetime. b. Jika datetime cocok maka proses Core User berjalan. c. Jika datetime tidak cocok maka sistem akan mengirimkan result sleep dan mengirimkan notify ke user. d. Setelah user menerima notify maka user dapat melakukan force proses Core User. e. Jika datetime cocok atau user melakukan force proses maka pembentukan file JSON untuk data User berjalan dan selanjutnya file JSON di store pada server ElasticSearch. f. Sistem akan mengirimkan notify terkait proses Core User berupa result sukses maupun gagal ke user.
10. Sequence Diagram FeaturedCustomer Gambar 4.2.5. 10 Sequence Diagram Core User. Deskripsi diagram sequence a. Sistem mulai melakukan pengecekan datetime. b. Jika datetime cocok maka proses Featured Customer berjalan. c. Jika datetime tidak cocok maka sistem akan mengirimkan result sleep dan mengirimkan notify ke user. d. Setelah user menerima notify maka user dapat melakukan force proses Featured Customer. e. Jika datetime cocok atau user melakukan force proses maka pembentukan file JSON untuk data Featured Customer berjalan dan selanjutnya file JSON di store pada Redis Server. f. Sistem akan mengirimkan notify terkait proses Core User berupa result sukses maupun gagal ke user.
11. Sequence Diagram CustomerModify Gambar 4.2.5. 11 Sequence Diagram Consumer Modify. Deskripsi diagram sequence a. Sistem mulai melakukan pengecekan datetime. b. Jika datetime cocok maka proses Customer Modify berjalan. c. Jika datetime tidak cocok maka sistem akan mengirimkan result sleep dan mengirimkan notify ke user. d. Setelah user menerima notify maka user dapat melakukan force proses Customer Modify. e. Jika datetime cocok atau user melakukan force proses maka proses update data status Customer berjalan. f. Sistem akan mengirimkan notify terkait proses Customer Modify berupa result sukses maupun gagal ke user.
12. Sequence Diagram ConsumerModify Gambar 4.2.5. 12 Sequence Diagram Consumer Modify. Deskripsi diagram sequence a. Sistem mulai melakukan pengecekan datetime. b. Jika datetime cocok maka proses Consumer Modify berjalan. c. Jika datetime tidak cocok maka sistem akan mengirimkan result sleep dan mengirimkan notify ke user. d. Setelah user menerima notify maka user dapat melakukan force proses Consumer Modify. e. Jika datetime cocok atau user melakukan force proses maka proses update data status Consumer berjalan. f. Sistem akan mengirimkan notify terkait proses Consumer Modify berupa result sukses maupun gagal ke user.
4.2.7 Class Diagram Class diagram juga menjelaskan hubungan antar class dalam sebuah sistem yang sedang dibuat dan bagaimana caranya agar mereka saling berkolaborasi untuk mencapai sebuah tujuan. 1. Class Diagram Bank Inquiry 2. Class Diagram Master Customer
3. Class Diagram Master Consumer 4. Class Diagram Alert Notify Customer
5. Class Diagram CustomerLog 6. Class Diagram ConsumerLog
7. Class Diagram CoreUser 8. Class Diagram FeaturedCustomer
9. Class Diagram Customer Modify 10. Class Diagram Consumer Modify