16 3 BAB III
METODE PENELITIAN
Bab ini menjelaskan mengenai metode penelitian yang akan dilakukan untuk mengerjakan penelitian ini, berupa metode Reuse-Oriented Development meliputi beberapa tahapan-tahapan yang harus di lalui.
Metode penelitian ini dimulai dengan studi literatur untuk memahami teori terkait penelitian yang dilakukan. Selanjutnya pemodelan proses bisnis yang dilakukan untuk mendefinisikan proses serta memodelkan aliran aktivitas bisnis dan prosedur yang berjalan, Namun demikian, dalam penelitian ini proses bisnis tidak disusun terpisah dalam suatu perencanaan, melainkan berdasarkan penelitian Andri Fajarullah (2019), yang menghasilkan sistem perijinan balai besar konservasi sumber daya alam (bbksda) jawa timur. Spesifikasi persyaratan merupakan tahapan untuk mengetahui semua spesifikasi persyaratan yang dibutuhkan sistem. Analisis komponen merupakan tahapan pengumpulan komponen yang dapat digunakan ulang dalam penelitian. Modifikasi persyaratan merupakan tahapan untuk menentukan modifikasi yang akan dilakukan. Perancangan sistem pemakaian ulang merupakan tahapan merancang arsitektur sistem yang akan diimplementasikan berdasarkan komponen reuse yang tersedia. Implementasi merupakan tahapan pengembangan sistem dan melakukan integrasi terhadap komponen reuse sehingga membentuk sistem baru. Tahapan terakhir yaitu pengujian dan analisis untuk menjamin sistem sudah memenuhi harapan sesuai spesifikasi persyaratan.
3.1 Analisis Persyaratan (Requirements Analysis)
Tahap ini, penulis melakukan proses elisitasi kebutuhan, identifikasi aktor, spesifikasi kebutuhan, verifikasi dan validasi. Proses-proses dalam tahapan ini bertujuan untuk mendapatkan spesifikasi persyaratan sistem yang dilakukan dengan metode wawancara kepada stakeholder dan observasi lapangan.
3.1.1 Elisitasi
Elisitasi merupakan rancangan dibuat berdasarkan sistem yang baru yang diinginkan oleh pihak Balai Besar Konservasi Sumber Daya Alam (BBKSDA) Jawa Timur dan disanggupi oleh peneliti untuk dieksekusi. Elisitasi didapat melalui metode wawancara dan dilakukan melalui tiga tahap:
17 a. Elisitasi Tahap I
Elisitasi tahap pertama ini berisi rancangan sistem baru yang diusulkan oleh pihak Balai Besar Konservasi Sumber Daya Alam (BBKSDA) Jawa Timur dengan melakukan wawancara antara pengurus asrama dengan peneliti.
Tabel 3.1 Elisitasi Tahap I
No Kebutuhan
1. Sistem mampu menerima inputan log-in
2. Sistem mampu menampilkan data calon perijinan
3. Sistem mampu menambah, meng-update, dan menghapus data calon perijinan
4. Sistem mampu mengubah status antrian data calon perijinan 5. Sistem mampu menampilkan pilihan wilayah perijinan 6. Sistem mampu mendownload format proposal perijinan
7. Sistem mampu menampilkan form pengisian data calon perijinan
8. Sistem mampu menampilkan status data antrian dan jadwal pengecekan kendang calon perijinan
b. Elisitasi Tahap II
Elisitasi tahap kedua ini merupakan hasil pengklasifikasian dari elisitasi tahap I berdasarkan metode MDI (Mandatory, Desirable, Inessential). Metode MDI ini bertujuan untuk memisahkan antara rancangan sistem yang penting dan harus ada pada sistem baru dengan rancangan yang disanggupi oleh peneliti untuk dieksekusi Penjelasan dari MDI (Mandatory, Desirable, Inessential) sebagai berikut :
1. Mandatory
Requirement tersebut harus ada dan tidak boleh dihilangkan pada saat membuat sistem baru
2. Desirable
Requirement tersebut tidak terlalu penting dan boleh dihilangkan.
Tetapi jika requirement tersebut digunakan dalam pembentukan sistem, akan membuat sistem tersebut lebih sempurna.
18 3. Inessential
Requirement tersebut bukanlah bagian dari sistem yang dibahas dan merupakan bagian dari luar sistem.
Tabel 3.2 Elisitasi Tahap II
No Kebutuhan M D I
1. Sistem mampu menerima inputan log-in √
2. Sistem mampu menampilkan data calon perijinan √ 3. Sistem mampu menambah, meng-update, dan menghapus data
calon perijinan
√
4. Sistem mampu mengubah status antrian data calon perijinan √ 5. Sistem mampu menampilkan pilihan wilayah perijinan
6. Sistem mampu mendownload format proposal perijinan √ 7. Sistem mampu menampilkan form pengisian data calon
perijinan
√
8. Sistem mampu menampilkan status data antrian dan jadwal pengecekan kendang calon perijinan
√
c. Elisitasi Tahap III
Merupakan hasil penyusutan elisitasi tahap II dengan cara mengeliminasi semua requirement dengan option I pada metode MDI. Selanjutnya semua requirement yang tersisa diklasifikasikan kembali melalui metode TOE, yaitu:
1. Tehnikal
Bagaimana tata cara / tehnik pembuatan requirement tersebut dalam sistem yang dikembangkan
2. Operasional
Bagaimana tata cara penggunaan requirement tersebut dalam sistem yang akan dikembangkan
3. Ekonomi
Berapa biaya yang diperlukan untuk membangun sistem tersebut berdasar requirement yang ada.
Metode TOE ini memiliki beberapa option yaitu :
19
• High (H) : Sulit untuk dikerjakan, karena tehnik pembuatan dan pemakaiannya sulit serta biayanya mahal. Sehingga requirement tersebut harus dieliminasi.
• Middle (M) : Mampu untuk dikerjakan, karena teknik pembuatan dan pemakaiannya tidak terlalu sulit serta biaya yang dikenakan tidak terlalu mahal.
• Low (L) : Mudah untuk dikerjakan, karena teknik pembuatan dan pemakaiannya mudah serta biaya yang dikenakan tidak terlalu mahal.
Tabel 3.3 Elisitasi Tahap III
No Kebutuhan T O E
H M L H M L H M L 1. Sistem mampu menerima inputan
log-in
√ √ √
2. Sistem mampu menampilkan data calon perijinan
√ √ √
3. Sistem mampu menambah, meng- update, dan menghapus data calon perijinan
√ √ √
4. Sistem mampu menampilkan pilihan wilayah perijinan
√ √ √
5. Sistem mampu mengubah status antrian data calon perijinan
√ √ √
6. Sistem mampu mendownload format proposal perijinan
√ √ √
7. Sistem mampu menampilkan form pengisian data calon perijinan
√ √ √
20 8. Sistem mampu menampilkan status
data antrian dan jadwal pengecekan kendang calon perijinan
√ √ √
3.1.2 Analisa Kebutuhan Fungsionnal
Kebutuhan fungsional adalah fungsi atau fitur apa saja yang terdapat didalam sistem, dan beberapa peran aktor dalam sistem. mencakup bagaimana sistem harus bereaksi pada input tertentu dan bagaimana perilaku sistem pada situasi tertentu.Berikut ini merupakan hasil analisa kebutuhan fungsional pada sistem.
Tabel 3.4 Kebutuhan Fungsional Sistem Perijinan
No Kebutuhan Fungsional
1 memilih wilayah pendaftaran 2 download format proposal perijinan 3 mengisi form perijinan
4 melihat status hasil perijinan
5 melihat jadwal pengecekan kandang 5 mengelola semua data form perijinan 6 mengelola semua data status hasil perijinan 7 mengelola data form perijinan di kantor cabang 8 mengelola data status hasil perijinan di kantor cabang 3.1.3 Analisa Kebutuhan Non-Fungsional
Analisa kebutuhan non fungsional merupakan kebutuhan yang menentukan kriteria yang menjadi suatu fungsi dalam sistem ini, dari kebutuhan non fungsional ini melibatkan analisa kebutuhan pengguna dan analisa kebutuhan sistem. Berikut adalah kebutuhan non fungsional tersebut:
21
Tabel 3.5 Kebutuhan Non-Fungsional Sistem Perijinan
No Kebutuhan Non-Fungsional
1 Aplikasi web tersebut dibuat menggunakan Bahasa pemrograman PHP dan penyimpanan database MySQL.
2 Aplikasi web tersebut memiliki desain antarmuka yang mudah dimengerti oleh user.
3 Bahasa yang digunakan pada website harus komunikatif dan menarik sehingga mudah untuk dipahami user.
3.1.4 Use Case
Berdasarkan hasil Persyaratan fungsional tersebut maka dapat dimodelkan ke dalam diagram use-case yang dapat digunakan untuk menggambarkan interaksi aktor dengan sistem seperti gambar berikut :
3.1.5 Identifikasi Aktor
Tahap ini peneliti mengidentifikasi Actor yang ada dan saling mempengaruhi dalam sistem. Actor yang ada dalam sistem ini, ada 3 yaitu Super Admin (pihak yang berwenang terhadap proses pengolahan data di pusat dan cabang ), Admin (pihak yang berwenang terhadap proses pengolahan data di cabang), dan User (Pihak yang melakukan izin penangkaran). Actor inilah yang akan berinteraksi dengan sistem karena berperan dalam menjalankan sistem ini.berdasarkan indentifikasi yang sudah di lakukan maka didapatkan interkasi antara Actor dan sistem :
Gambar 3.1 Use Case Diagram
22 1. Super Admin (Petugas Pusat)
- Login Dashboard utama - Mengelola data di kantor pusat - Dapat melihat data di kantor cabang
- Dabat mengupdate semua status data pemohon 2. Admin Petugas Cabang (Petugas Cabang)
- Login dashboard utama
- Mengelola data pemohon di kantor cabang - Menentukan jadwal pengecekan kandang 3. User
- Memilih wilayah izin penangkaran - Menginput data permohonan izin - Mengecek antrian data
- Melihat jadwal kendang 3.1.6 Activity Diagram
Tahap ini peneliti hanya menggambarkan secara umum dari masing- masing aktivitas yang telah dikembangkan dalam sistem.
3.1.6.1 Activity Diagram Super Admin
Berdasarkan gambar 3.2 menjelelaskan alur diagram aktivitas sistem perijinan,antara actor dan sistem pada proses login. Sesudah aktor mengkses
Gambar 3.2 Activity diagram login
23
laman login, sistem akan menampilkan form login untuk input username dan password untuk di validasi. Apabila input data yang dimasukkan tidak valid maka akan Kembali ke menu login dan jika berhasil maka aktivitas berakhir
Berdasarkan gambar 3.3 menjelaskan alur diagram aktivitas Sistem Perijinan, antara aktor dan sistem pada proses create. Sesudah aktor login, sistem akan merequest data dan hasil request datanya ditampilkan ke layar aktor. Sehingga, aktor dapat melihat datanya, serta memilih tombol atau aksi apa yang diinginkan, mulai dari tombol atau aksi create yang sudah disediakan oleh Sistem Perijinan. Fungsi tombol atau aksi create menampilkan form untuk mengisi data pada Sistem Perijinan.
Gambar 3.3 Activity diagram create
Gambar 3.4 Activity diagram update
24
Berdasarkan gambar 3.4 menjelaskan alur diagram aktivitas Sistem Perijinan, antara aktor dan sistem pada proses update. Sesudah aktor login, sistem akan merequest data dan hasil request datanya ditampilkan ke layar aktor. Sehingga, aktor dapat melihat datanya, serta memilih tombol atau aksi apa yang diinginkan, mulai dari tombol atau aksi Update yang sudah disediakan oleh Sistem Perijinan. Fungsi tombol atau aksi Update menampilkan form untuk meng-update pada Sistem Perijinan.
Berdasarkan gambar 3.5 menjelaskan alur diagram aktivitas SistemPerijinan, antara aktor dan sistem pada proses delete. Sesudah aktor login, sistem akan merequest data dan hasil request datanya ditampilkan ke layar aktor. Sehingga, aktor dapat melihat datanya, serta memilih tombol atau aksi apa yang diinginkan, mulai dari tombol atau aksi Delete yang sudah disediakan oleh Sistem Perijinan. Fungsi tombol atau aksi Delete menampilkan form untuk menghapus pada Sistem Perijinan.
Gambar 3.5 Activity diagram delete
25
Berdasarkan gambar 3.6 menjelaskan alur diagram aktivitas Sistem Perijinan, antara aktor dan sistem pada proses update status data. Sesudah aktor login, sistem akan merequest data dan hasil request datanya ditampilkan ke layar aktor. Sehingga, aktor dapat melihat datanya, serta memilih tombol atau aksi apa yang diinginkan, mulai dari merubah status data dari Terkirim (Sending), Pengecekan (Checking), Diterima (Confirm), Ditolak (Canceled).
3.1.6.2 Activity Diagram Admin
Gambar 3.6 Activity diagram status perijinan
Gambar 3.7 Activity diagram login
26
Berdasarkan gambar 3.7 menjelelaskan alur diagram aktivitas sistem perijinan,antara actor dan sistem pada proses login. Sesudah aktor mengkses laman login, sistem akan menampilkan form login untuk input username dan password untuk di validasi. Apabila input data yang dimasukkan tidak valid maka akan Kembali ke menu login dan jika berhasil maka aktivitas berakhir.
Berdasarkan gambar 3.8 menjelaskan alur diagram aktivitas Sistem Perijinan, antara aktor dan sistem pada proses create. Sesudah aktor login, sistem akan merequest data dan hasil request datanya ditampilkan ke layar aktor. Sehingga, aktor dapat melihat datanya, serta memilih tombol atau aksi apa yang diinginkan, mulai dari tombol atau aksi create yang sudah disediakan oleh Sistem Perijinan. Fungsi tombol atau aksi create menampilkan form untuk mengisi data pada Sistem Perijinan.
Gambar 3.8 Activity diagram create
27
Berdasarkan gambar 3.9 menjelaskan alur diagram aktivitas Sistem Perijinan, antara aktor dan sistem pada proses update. Sesudah aktor login, sistem akan merequest data dan hasil request datanya ditampilkan ke layar aktor. Sehingga, aktor dapat melihat datanya, serta memilih tombol atau aksi apa yang diinginkan, mulai dari tombol atau aksi Update yang sudah disediakan oleh Sistem Perijinan.
Fungsi tombol atau aksi Update menampilkan form untuk meng-update pada Sistem Perijinan, Ditahap ini admin dapat mengupdate inputan proposal user.
Gambar 3.9 Activity diagram delete Gambar 3.10 Activity diagram update
28
Berdasarkan gambar 3.10 menjelaskan alur diagram aktivitas Sistem Perijinan, antara aktor dan sistem pada proses delete. Sesudah aktor login, sistem akan merequest data dan hasil request datanya ditampilkan ke layar aktor. Sehingga, aktor dapat melihat datanya, serta memilih tombol atau aksi apa yang diinginkan, mulai dari tombol atau aksi Delete yang sudah disediakan oleh Sistem Perijinan.
Fungsi tombol atau aksi Delete menampilkan form untuk menghapus pada Sistem Perijinan.
3.1.6.3 Activity Diagram User
Berdasarkan gambar 3.11 menjelaskan alur diagram aktivitas Sistem Perijinan, antara aktor dan sistem pada proses user download. Setelah actor membuka laman BBKSDA, system akan merequest data dan menampilkan laman yang di pilih oleh actor. Kemudian, actor membaca tahapan-tahapan perijinan pada laman yang ditampilkan dan download proposal pada laman tersebut.
Gambar 3.11 Activity diagram download
29
Berdasarkan gambar 3.12 menjelaskan alur diagram aktivitas Sistem Perijinan, antara aktor dan sistem pada proses pilih wilayah .Setelah actor membaca tahapan dan melanjutkan kepada laman tahapan pilih wilayah BKSDA, system akan merequest data dan menampilkan laman perijinan yang dipilih actor. Kemudian, actor mengisikan data yang diperlukan kepada system dan sitem akan menerima lalu mengkonfirmasi apakah data yang dimasukkan sudah terpenuhi atau tidak.
Gambar 3.13 Activity diagram pilih wilayah
Gambar 3.12 Activity diagram input data
30
Berdasarkan gambar 3.13 menjelaskan alur diagram aktivitas Sistem Perijinan, antara aktor dan sistem pada proses input. Setelah actor membaca tahapan dan melanjutkan kepada laman tahapan input data, system akan merequest data dan menampilkan laman perijinan yang dipilih actor.
Kemudian, actor mengisikan data yang diperlukan kepada system dan sitem akan menerima lalu mengkonfirmasi apakah data yang dimasukkan sudah terpenuhi atau tidak.
Berdasarkan gambar 3.14 menjelaskan alur diagram aktivitas Sistem Perijinan, antara aktor dan sistem pada proses antrian data. Setelah actor input data dan data terpenuhi, actor juga bias melakukan melihat status antrian datanya dengan membuka laman antrian data, system akan merquest data dan menampilkan laman yang dipilih oleh actor. Kemudian actor memasukkan ID data untuk mencari status datanya. Lalu system akan menampilkan feedback dari pencarian data tersebut melalui ID data user.
Gambar 3.14 Activity diagram pengecekan kandang
31
Berdasarkan gambar 3.15 menjelaskan alur diagram aktivitas Sistem Perijinan, antara aktor dan sistem pada proses jadwal pengecekan kendang, Setelah actor input data dan data terpenuhi, actor juga bisa melakukan melihat jadwal pengecekan kendang dengan membuka laman antrian data, system akan merquest data dan menampilkan laman yang dipilih oleh actor. Kemudian actor memasukkan ID data untuk mencari status datanya. Lalu system akan menampilkan feedback dari pencarian data tersebut melalui ID data user.
3.2 Analisis Komponen
Tahapan analisis komponen dilakukan untuk mencari komponen yang sesuai dengan spesifikasi persyaratan [6]. Sommerville menambahkan bahwa komponen yang telah ditentukan biasanya tidak ada kecocokan yang tepat melainkan hanya tersedia beberapa fungsi saja. berikut merupakan daftar komponen yang digunakan ulang beserta kegunaannya :
Tabel 12 Daftar komponen yang digunakan ulang
Nama Kegunaan
CodeIgniter Sebagai framework
Source Code Untuk memudahkan dalam pembuatan fungsi dan logika yang dibutuhkan sistem
Gambar 3.15 Activity diagram antrian data
32
Admin LTE Sebagai tampilan dashboard
Web Service API BAIS Sebagai otentikasi akun Super Admin dan Admin
3.3 Modifikasi Persyaratan
Tahapan ini melakukan alisis perubahan yang dibutuhkan atau modifikasi yang akan dilakukan pada komponen-komponen yang telah didapatkan. Berikut dalam Tabel 13 merupakan komponen yang dilakukan modifikasi.
Tabel 13 Dafar komponen yang dimodifikasi
Nama Perubahan yang di lakukan
Web Service API BAIS
Sebelum : Output yang didapatkan dari API BAIS berupa JSON.
Sesudah : Diubah kedalam format array dan hanya diambil beberapa value saja
3.4 Perancangan Dengan Komponen
Tahap ini perancangan yang dilakukan meliputi perancangan arsitektur sistem, perancangan interaksi objek, perancangan kelas objek, perancangan basis data, dan integrasi komponen.
Upaya perancangan arsitektur sistem menggunakan pola perancangan MVC (model-view-controller). Sedangkan dalam perancangan interaksi objek digambarkan ke dalam sequence diagram yang bertujuan agar memudahkan programmer melakukan pengambangan sistem dalam membuat fungsi dan interaksi yang dilakukan antar kelas.
3.4.1 Sequence Diagram
Sequence diagram digunakan peneliti untuk menggambarkan rancangan interaksi objek agar memudahkan programmer melakukan pengembangan sistem dalam membuat fungsi dan interaksi yang di lakukan antar kelas. Ada beberapa sequence diagram yang digambarkan seperti sequence diagram login, sequence diagram create, sequence diagram update, sequence diagram delete, sequence diagram status antrian perijinan, sequence diagram download,
33
sequence diagram pilih wilayah, sequence diagram input data, sequence diagram antrian data, dan sequence diagram jadwal pengecekan kendang.
3.4.1.1 Sequence diagram Super admin dan Admin Diagram User
Berdasarkan gambar 3.16 menjelaskan alur diagram sekuen yang terjadi didalam sistem saat proses “login” secara umum. Superadmin/admin membuka laman login penangkaran setelah itu controller mengeksekusi perintah lalu controller akan request data dari model setelah data sudah didapatkan controller akan menampilkan laman login, setelah itu superadmin atau admin memasukan username dan password dan view akan memanggil controller untuk request data dari model. Model akan mevalidasi username dan password.
Jika valid maka controller akan menampilkan laman dashboard pada view, tetapi jika tidak valid maka view akan menampilkan kembali laman login. Hal ini dilakukan berulang-ulang hingga data yang dimasukkan valid atau program di tutup (di non-aktifkan).
Gambar 3.16 Sequence diagram login
34
Berdasarkan gambar 3.17 menjelaskan alur diagram sekuen yang terjadi didalam sistem saat proses “create” , secara umum. Superadmin atau Admin mengklik menu data izin penangkaran setelah itu controller mengeksekusi perintah yang dipilih lalu controller akan request data dari model setelah data sudah didapatkan controller akan menampilkan laman data izin penangkaran, setelah itu superadmin atau admin mengklik menu addnew dan view akan memanggil controller tambah data izin penangkaran setelah berhasil maka controller akan memberikan form tambah data izin penangkaran lalu superadmin atau admin mengisi form jika sudah selesai maka view akan kembali memanggil controller tambah data izin penangkaran lalu controller memanggil model untuk menambahkan data pada database. Jika berhasil ditambahkan maka model akan memberi data data izin penangkaran pada controller lalu akan ditampilkan pada view.
Gambar 3.17 Sequence diagram create
35
Berdasarkan gambar 3.18 menjelaskan alur diagram sekuen yang terjadi didalam sistem saat proses “update”, secara umumnya saja. Superadmin atau Admin mengklik menu data izin penangkaran setelah itu controller mengeksekusi perintah yang dipilih oleh superadmin atau admin lalu controller akan request data dari model setelah data sudah didapatkan controller akan menampilkan data izin penangkaran, setelah itu petugas memilih data izin penangkaran yang akan diedit, lalu view akan memanggil controller edit data izin penangkaran dan controller memberi form edit dan menampilkannya pada view. Setelah mengedit data dan mengklik save maka controller akan memanggil model untuk mengedit data jika berhasil maka model akan memberi data pada controller dan ditampilkan pada view
Gambar 3.18 Sequence diagram update
36
Berdasarkan gambar 3.19 menjelaskan alur diagram sekuen yang terjadi didalam sistem saat proses “delete”, secara umum.Superadmin atau Admin mengklik menu data izin penangkaran setelah itu controller mengeksekusi perintah yang telah dipilih, lalu controller akan request data dari model setelah data sudah didapatkan controller akan menampilkan data izin penangkaran, setelah itu superadmin atau admin memilih data izin penangkaran yang akan dihapus lalu view akan memanggil controller hapus data izin penangkaran dan controller memanggil model hapus data izin penangkaran untuk menghapus data tersebut pada database.
Gambar 3.19 Sequence diagram delete
37
Berdasarkan gambar 3.20 menjelaskan alur diagram sekuen yang terjadi didalam sistem saat proses “update antrian data” secara umumnya saja. Super Admin mengklik menu data izin penangkaran setelah itu controller mengeksekusi perintah yang dipilih lalu controller akan request data dari model setelah data sudah didapatkan controller akan menampilkan data izin penangkaran, setelah itu admin memilih data izin penangkaran yang akan di ganti status antrian datanya, lalu view akan memanggil controller update data antrian izin penangkaran dan controller memberi form update dan menampilkannya pada view. Setelah itu Super admin mengedit data tersebut dan mengklik save setelah selesai maka controller akan memanggil model untuk mengedit data jika berhasil maka model akan memberi data pada controller dan ditampilkan pada view.
Gambar 3.20 Sequence diagram antrian data
38
Berdasarkan gambar 3.21 menjelaskan alur diagram sekuen yang terjadi didalam sistem saat proses “update Jadwal kandang” secara umumnya saja.
Super Admin mengklik menu data izin penangkaran setelah itu controller mengeksekusi perintah yang dipilih lalu controller akan request data dari model setelah data sudah didapatkan controller akan menampilkan data izin penangkaran, setelah itu admin memilih data izin penangkaran yang akan di atur jadwal pengekecekan kandangnya, lalu view akan memanggil controller update data izin penangkaran dan controller memberi form update dan menampilkannya pada view. Setelah itu Super admin mengedit data tersebut dan mengklik save setelah selesai maka controller akan memanggil model untuk mengedit data jika berhasil maka model akan memberi data pada controller dan ditampilkan pada view.
Gambar 3.21 Sequence diagram jadwal pengecekan kandang
39 3.4.1.2 Sequence Diagram User
Berdasarkan gambar 3.22 menjelaskan alur diagram sekuen yang terjadi didalam sistem saat proses “Input Data” secara umumnya saja. User mengklik menu perijinan setelah itu controller mengeksekusi perintah yang dipilih oleh user lalu controller akan menampilkan laman perijinan pada view kemudian user diharuskan untuk memilih form dan wilayah yang disediakan, lalu mengisi form perijinan dengan format yang telah disediakan, jika sudah maka controller akan mengirim data dengan memanggil model setelah itu model akan memberitahu bahwa data berhasil ditambahkan dan pemberitahuan tersebut akan ditampilkan pada view.
Gambar 3.22 Sequence diagram User input data
Gambar 3.23 Sequence diagram User Antrian Data dan jadwal cek kandang
40
Berdasarkan gambar 3.23 menjelaskan alur diagram sekuen yang terjadi didalam sistem saat proses “Antrian Data” secara umumnya saja. User mengklik menu Antrian Data setelah itu controller mengeksekusi perintah yang dipilih oleh user lalu controller akan menampilkan laman Antrian Data pada view kemudian user diharuskan untuk memasukkan id_data pada kolom pencarian yang disediakan, jika sudah maka controller akan memanggil data dengan memanggil di model setelah itu model akan memberitahu bahwa data berhasil ditemukan dan pemberitahuan tersebut akan ditampilkan pada view.
