• Tidak ada hasil yang ditemukan

BAB IV HASIL DAN PEMBAHASAN

4.1.5 Analisis Kebutuhan Sistem

Perancangan knowledge management system sesuai dengan sistem yang diusulkan memerlukan analisis terkait kebutuhan sistem sebagai berikut:

1. Sistem mampu melakukan proses penyimpanan pengetahuan.

2. Sistem mampu menyediakan layanan untuk mengelola pengetahuan.

3. Sistem dapat membantu proses sharing pengetahuan.

4. Sistem mampu menyediakan fasilitas diskusi antar karyawan.

5. Software yang digunakan dalam membangun sistem:

a. PHP b. HTML5 c. Laravel

d. PHPMyAdmin e. Visual Studio Code f. Draw.io

6. Hardware yang dibutuhkan untuk menjalankan sistem:

a. Minimum Processor Intel Core i3

98 b. RAM 2 GB

c. Harddisk 500 GB

4.2 Perancangan Desain 4.2.1 Perancangan Proses

4.2.1.1 Use Case Diagram

Use case diagram menggambarkan bagaimana aktor-aktor yang terlibat berinteraksi dengan sistem knowledge management di BAPPEDA Provinsi Lampung. Langkah awal yang dilakukan ialah mengidentifikasi aktor-aktor yang berinteraksi dengan sistem. Identifikasi aktor KMS BAPPEDA diuraikan pada tabel 4.3.

Tabel 4.3 Identifikasi Aktor KMS BAPPEDA

No. Aktor Deskripsi

1. Administrator Pihak yang mendapatkan hak akses dan bertanggung jawab penuh terhadap seluruh aktivitas yang terjadi di dalam sistem.

2. Kepala UPTD Pihak yang memiliki akses untuk login, logout, edit profil, membuat forum diskusi, membuat komentar, melakukan request, mencari, mendownload dan mengupload dokumen serta bertanggung jawab untuk mengelola dokumen, forum diskusi, dan komentar.

99 3. Karyawan BAPPEDA Pihak yang memiliki akses untuk login,

logout, edit profil, membuat forum diskusi, membuat komentar, melakukan request, mencari, men-download dan meng-upload dokumen.

Langkah selanjutnya setelah aktor diidentifikasi ialah mengidentifikasi use case apa saja yang dilakukan oleh aktor dalam berinteraksi dengan sistem. Identifikasi use case KMS BAPPEDA diuraikan pada tabel 4.4.

Tabel 4.4 Identifikasi Use Case

No. Nama Use Case

Deskripsi Aktor

1. Registrasi user

Use case ini menggambarkan kegiatan pendaftaran akun ke dalam sistem oleh Administrator.

Administrator

2. Login Use case ini menggambarkan kegiatan masuk ke dalam sistem menggunakan id dan password tertentu.

Administrator, Kepala UPTD, Karyawan 3. Logout Use case ini menggambarkan kegiatan

mengakhiri sesi atau keluar dari sistem.

Administrator, Kepala UPTD, Karyawan

100 4. Manajemen

user

Use case ini menggambarkan kegiatan mengelola user sistem.

Administrator

5. Edit profil Use case ini menggambarkan kegiatan mengubah elemen-elemen dalam profil masing-masing user.

Use case ini menggambarkan kegiatan mengelola dokumen yang ada di dalam

Use case ini menggambarkan kegiatan mencari dokumen yang tersedia di dalam sistem.

Use case ini menggambarkan kegiatan mengunggah dokumen ke dalam sistem.

Administrator, Kepala UPTD, Karyawan 9. Download

dokumen

Use case ini menggambarkan kegiatan mengunduh dokumen yang ada di sistem ke komputer user.

Use case ini menggambarkan kegiatan untuk meminta dokumen tertentu kepada seluruh pengguna sistem.

Use case ini menggambarkan kegiatan validasi dokumen yang telah terunggah

Administrator, Kepala UPTD

101 sehingga terjamin kredibilitas dan

akurasinya.

12. Forum diskusi

Use case ini menggambarkan kegiatan membuat, mengedit, menutup, menghapus, dan bergabung pada forum diskusi.

Administrator, Kepala UPTD, Karyawan

13. Komentar Use case ini menggambarkan kegiatan menambahkan, mengedit, ataupun menghapus komentar.

Administrator, Kepala UPTD, Karyawan Langkah selanjutnya setelah mengidentifikasi use case ialah menggambarkan interaksi antara aktor dengan use case yang terjadi di dalam KMS BAPPEDA. Use case diagram ini digambarkan pada Gambar 4.4.

102 Gambar 4.4 Use Case Diagram Knowledge Management System BAPPEDA

Use case yang terdapat pada diagram diatas perlu dilakukan penjelasan lebih lanjut terkait masing-masing use case yang disebut juga use case scenario. Tujuan dari use case scenario ini adalah untuk menjelaskan interaksi antara aktor dengan use case secara detil dan menyeluruh.

103 Tabel 4.5 Use Case Scenario Login

Use case name Login Use case ID 1

Actor Administrator, Kepala UPTD, Karyawan

Description

Use case ini menggambarkan kegiatan user untuk masuk ke dalam sistem dan mendapatkan hak akses.

Pre condition Aktor harus memiliki email dan password.

Typical course of event

Actor Action System Response 1. Aktor membuka halaman

login

2. Sistem menampilkan halaman login

3. Aktor menginput email dan password pada form

4. Aktor mengklik ‘Login’ 5. Verifikasi login oleh sistem

6. Sistem menampilkan halaman utama

Alternate courses

5a. Apabila gagal kembali ke step 3.

Conclusion Aktor berhasil masuk ke dalam sistem dan memiliki hak akses.

Post Condition -

104 Tabel 4.6 Use Case Scenario Mencari Dokumen

Use case name Mencari dokumen Use case ID 2

Actor Administrator, Ketua UPTD, Karyawan

Description

Use case ini menggambarkan kegiatan pencarian dokumen oleh user.

Pre condition -

Typical course of event

Actor Action System Response 1. Aktor membuka halaman

utama sistem

2. Sistem menampilkan halaman utama

3. Aktor memasukkan kata kunci pada kolom pencarian

4. Sistem mengakses database sistem

5. Sistem menampilkan hasil pencarian

Alternate courses

5a. Jika hasil tidak ditemukan, user dapat kembali ke step 3.

Conclusion

Use case berakhir ketika user berhasil menemukan dokumen yang diinginkan.

Post Condition

Sistem menampilkan dokumen-dokumen yang berkaitan dengan kata kunci pencarian.

Tabel 4.7 Use Case Scenario Download Dokumen Use case name Download dokumen

105 Use case ID 3

Actor Administrator, Kepala UPTD, Karyawan

Description

Use case ini menggambarkan kegiatan mengunduh dokumen yang diinginkan ke dalam komputer masing-masing user.

Pre condition Aktor telah login ke dalam sistem.

Typical course of event

Actor Action System Response 1. Aktor membuka halaman

index

2. Sistem menampilkan halaman index

3. Aktor memilih dokumen 4. Sistem menampilkan halaman dokumen

5. Aktor mengklik tombol

‘download’

6. Sistem mengakses database

7. Sistem menampilkan jendela download

8. Aktor mengklik tombol

‘OK’

9. Dokumen berhasil di-download ke komputer user.

Alternate courses

6a. Aktor dapat memilih ‘Batal’.

Conclusion

Use case berakhir ketika user berhasil mengunduh dokumen yang diinginkan ke komputer user.

Post Condition -

106 Tabel 4.8 Use Case Scenario Request Dokumen

Use case name Request dokumen Use case ID 4

Actor Administrator, Kepala UPTD, Karyawan

Description

Use case ini menggambarkan kegiatan request/meminta kepada user lain untuk meng-upload dokumen sesuai dengan deskripsi request.

Pre condition Aktor telah login ke dalam sistem.

Typical course of event

Actor Action System Response 1. Aktor membuka menu

‘Request’

2. Sistem menampilkan halaman request.

3. Aktor mengklik ‘Tambah Request’

4. Sistem menampilkan form tambah request.

5. Aktor menginput data dan klik ‘Simpan’

6. Sistem memverifikasi data

7. Sistem mengonfirmasi request berhasil dibuat.

Alternate courses

3a. Aktor dapat memilih daftar request yang ada.

4a. Sistem menampilkan halaman request.

5a. Aktor mengupload data dokumen.

6a. Sistem memverifikasi dokumen.

7a. Sistem mengonfirmasi dokumen berhasil di-upload dan menunggu validasi.

107 Conclusion

Use case berakhir ketika user berhasil membuat request dokumen yang diinginkan.

Post Condition

Dokumen yang telah di-upload harus divalidasi oleh Administrator.

Tabel 4.9 Use Case Scenario Upload Dokumen Use case name Upload dokumen

Use case ID 5

Actor Administrator, Kepala UPTD, Karyawan

Description

Use case ini menggambarkan kegiatan upload dokumen kedalam sistem.

Pre condition Aktor telah login ke dalam sistem.

Typical course of event

Actor Action System Response 1. Aktor membuka menu index 2. Sistem menampilkan

halaman index 3. Aktor mengklik tombol

‘Upload Dokumen’

4. Sistem menampilkan form upload dokumen.

5. Aktor menginput data dan meng-upload dokumen.

6. Sistem memverifikasi data

7. Sistem mengonfirmasi data dokumen berhasil di-upload dan menunggu validasi.

108 Alternate

courses

6a. Apabila error kembali ke step 5.

Conclusion Use case berakhir ketika berhasil melakukan upload dokumen.

Post Condition

Dokumen yang telah di-upload harus divalidasi oleh Administrator.

Tabel 4.10 Use Case Scenario Validasi Dokumen Use case name Validasi dokumen

Use case ID 6

Actor Administrator

Description

Use case ini menggambarkan kegiatan untuk mengubah status validasi atas dokumen yang telah di-upload sehingga data dapat muncul pada menu index.

Pre condition Aktor telah login ke dalam sistem.

Typical course of event

Actor Action System Response 1. Aktor membuka menu

‘Validasi Dokumen’

2. Sistem menampilkan halaman validasi

3. Aktor memilih dokumen yang akan divalidasi

4. Sistem menampilkan halaman dokumen

5. Aktor mengecek validitas lalu klik ‘Valid’

6. Sistem mengonfirmasi dokumen berhasil divalidasi dan kembali ke halaman validasi

109 Alternate

courses

5a. Aktor dapat memilih ‘Tidak Valid’.

6a. Sistem mengonfirmasi dokumen gagal divalidasi.

Conclusion

Use case berakhir ketika user berhasil melakukan validasi dokumen.

Post Condition Dokumen yang telah divalidasi akan muncul di halaman index.

Tabel 4.11 Use Case Scenario Manajemen Dokumen Use case name Manajemen dokumen

Use case ID 7

Actor Administrator, Kepala UPTD

Description

Use case ini menggambarkan kegiatan pengelolaan dokumen dimana aktor dapat menambah, mengedit ataupun menghapus dokumen yang tidak relevan.

Pre condition Aktor telah login ke dalam sistem dan membuka menu index.

Typical course of event

Actor Action System Response 1. Aktor memilih dokumen

pada menu index

2. Sistem menampilkan halaman dokumen yang dipilih

3. Aktor mengklik tombol

‘Edit’

4. Sistem mengakses

database dan

menampilkan form edit dengan data sebelumnya.

110 5. Aktor menginput data yang

akan diedit dan klik

‘Simpan’

6. Sistem memverifikasi data

7. Sistem mengonfirmasi data dokumen berhasil diedit dan menunggu validasi.

Alternate courses

3a. Aktor dapat memilih ‘Hapus’.

4a. Sistem menampilkan jendela konfirmasi hapus dokumen.

5a. Aktor mengklik ‘Hapus’.

6a. Sistem menghapus data dokumen 7a. Sistem menampilkan halaman index 3b. Aktor dapat memilih ‘Kembali’.

4b. Sistem menampilkan halaman index.

Conclusion

Use case berakhir ketika user berhasil mengubah atau menghapus data.

Post Condition Dokumen yang diubah selanjutnya akan divalidasi oleh admin.

Tabel 4.12 Use Case Scenario Komentar Use case name Komentar

Use case ID 8

Actor Administrator, Kepala UPTD, Karyawan

111 Description

Use case ini menggambarkan kegiatan menambah, mengedit, membalas dan mengedit komentar pada kolom komentar dokumen dan request.

Actor Action System Response 1. Aktor mengklik ‘Tambah

Komentar’

2. Sistemenampilkan form tambah komentar

3. Aktor menginput data dan klik ‘Simpan’

4. Sistem mengonfirmasi komentar berhasil

2a. Sistem mengakses database dan menampilkan form dengan data sebelumnya.

3a. Aktor mengedit data dan klik ‘Simpan’

4a. Sistem mengonfirmasi komentar berhasil di edit.

1b. Aktor dapat memilih ‘Hapus’.

2b. Sistem menampilkan jendela konfirmasi.

3b. Aktor mengklik ‘Ya’.

4b. Sistem menghapus komentar dari sistem.

Conclusion Use case berakhir ketika user berhasil membuat komentar.

112 Post Condition

Komentar yang telah dibuat akan muncul pada kolom komentar.

Tabel 4.13 Use Case Scenario Forum Diskusi Use case name Forum diskusi

Use case ID 9

Actor Administrator, Kepala UPTD

Description

Use case ini menggambarkan kegiatan membuat, mengedit, menutup, serta menghapus forum diskusi.

Pre condition Aktor telah login ke dalam sistem dan membuka menu Forum.

Typical course of event

Actor Action System Response 1. Aktor mengklik ‘Buat

Forum’

2. Sistem menampilkan form buat forum

3. Aktor menginput data lalu klik ‘Simpan’

4. Sistem memverifikasi data

5. Sistem mengonfirmasi forum diskusi berhasil dibuat dan menampilkan halaman forum.

Alternate courses

1a. Aktor dapat klik forum yang dibuat lalu klik ‘Edit’.

2a. Sistem menampilkan form edit dengan data sebelumnya.

3a. Aktor mengedit data lalu klik ‘Simpan’.

5a. Sistem mengonfirmasi forum berhasil diedit.

113 1b. Aktor dapat klik forum yang dibuat lalu klik ‘Tutup’.

2b. Sistem menampilkan jendela konfirmasi.

3b. Aktor mengklik ‘Tutup’.

4b. Sistem mengonfirmasi forum berhasil ditutup.

1c. Aktor dapat klik forum yang dibuat lalu klik ‘Hapus’.

2c. Sistem menampilkan jendela konfirmasi.

3c. Aktor mengklik ‘Hapus’.

4c. Sistem mengonfirmasi forum berhasil dihapus.

1d. Aktor dapat klik pada salah satu forum.

2d. Sistem menampilkan halaman forum.

3d. Aktor mengisi kolom diskusi lalu klik ‘Kirim’.

4d. Sistem menampilkan halaman forum.

Conclusion

Use case berakhir ketika user berhasil mengedit, menutup dan menghapus forum diskusi.

Post Condition

Forum yang ditutup tidak akan bisa digunakan untuk berdiskusi kembali, kecuali forum telah dibuka kembali.

Forum yang dihapus akan hilang dari menu forum.

Tabel 4.14 Use Case Scenario Manajemen User Use case name Manajemen user

Use case ID 10

Actor Administrator

114 Description

Use case ini menggambarkan kegiatan pengelolaan terhadap user yaitu mengedit dan menghapus user oleh administrator.

Pre condition

Aktor telah login ke dalam sistem dan membuka halaman manajemen user.

Typical course of event

Actor Action System Response 1. Aktor membuka halaman

manajemen user

2. Sistem menampilkan halaman manajemen user 3. Aktor memilih user yang

diinginkan lalu klik ‘Edit’

4. Sistem mengakses

database dan

menampilkan form sesuai data sebelumnya.

5. Aktor menginput data yang diedit lalu klik ‘Simpan’

6. Sistem memverifikasi data

7. Sistem mengonfirmasi user berhasil diubah dan kembali ke halaman manajemen user

Alternate courses

3a. Aktor dapat memilih ‘Hapus’.

4a. Sistem menampilkan jendela konfirmasi.

5a. Aktor mengklik ‘Hapus’.

6a. Sistem mengonfirmasi user berhasil di hapus.

Conclusion

Use case berakhir ketika user berhasil mengubah atau menghapus data user.

115 Post Condition -

Tabel 4.15 Use Case Scenario Registrasi User Use case name Registrasi user

Use case ID 11

Actor Administrator

Description

Use case ini menggambarkan kegiatan pendaftaran user sistem oleh Administrator sesuai dengan level, jabatan, serta bidang masing-masing user.

Actor Action System Response 1. Aktor mengklik ‘Tambah

user’

2. Sistem menampilkan form tambah user

3. Aktor menginput data dan klik ‘Simpan’.

4. Sistem memverifikasi data

5. Sistem mengonfirmasi

user berhasil

4a. Jika eror kembali ke step 3.

116 Conclusion Use case berakhir ketika user berhasil ditambahkan.

Post Condition

Data user yang ditambahkan telah tersimpan di dalam sistem sehingga user bisa melakukan login.

Tabel 4.16 Use Case Scenario Edit Profil Use case name Edit Profil

Use case ID 12

Actor Administrator, Kepala UPTD, Karyawan

Description

Use case ini menggambarkan kegiatan pengubahan akun masing-masing user.

Pre condition

Aktor telah login ke dalam sistem dan membuka halaman profil.

Typical course of event

Actor Action System Response 1. Aktor mengklik tombol

‘Edit Profil’

2. Sistem mengakses

database dan

menampilkan form edit dengan data sebelumnya.

3. Aktor menginput data yang akan diedit dan klik

‘Simpan’

4. Sistem memverifikasi data

5. Sistem mengonfirmasi profil berhasil diedit.

117 Alternate

courses

4a. Apabila gagal kembali ke step 3.

Conclusion Use case berakhir ketika user berhasil mengubah data profil.

Post Condition Data pada halaman profil berubah.

Tabel 4.17 Use Case Scenario Logout Use case name Logout

Use case ID 13

Actor Administrator, Kepala UPTD, Karyawan

Description Use case ini menggambarkan kegiatan untuk keluar dari sistem.

Pre condition Aktor telah login ke dalam sistem.

Typical course of event

Actor Action System Response 1. Aktor mengklik ‘Logout’ 2. Sistem memproses keluar

dari sistem

3. Aktor berhasil logout dan sistem menampilkan halaman utama.

Alternate courses

-

Conclusion Aktor berhasil keluar dari sistem.

Post Condition -

118 4.2.1.2 Activity Diagram

Activity diagram memperlihatkan alur proses atau langkah-langkah aktivitas dari use case yang telah ditetapkan sebelumnya.

a. Mencari Dokumen

Aktivitas ini menggambarkan kegiatan mencari dokumen yang dilakukan oleh aktor. Aktor tidak perlu login untuk melakukan pencarian dokumen. Aktor hanya perlu membuka halaman utama dimana telah terdapat kolom pencarian didalamnya. Kondisi yang muncul apabila data tidak ditemukan adalah aktor dapat melakukan pencarian lebih lanjut dengan memasukkan kata kunci yang lain.

Gambar 4.5 Activity Diagram Mencari Dokumen

119 b. Download Dokumen

Aktivitas ini menggambarkan kegiatan men-download dokumen yang dilakukan oleh aktor. Aktor terlebih dahulu harus login ke dalam sistem untuk dapat men-download dokumen.

Gambar 4.6 Activity Diagram Download Dokumen

120 c. Manajemen Dokumen

Aktvitas ini menggambarkan kegiatan aktor dalam mengelola dokumen seperti melakukan edit dan hapus dokumen yang ada di dalam sistem. Aktor perlu melakukan login untuk dapat melakukan aktivitas ini.

Gambar 4.7 Activity Diagram Manajemen Dokumen

121 d. Request Dokumen

Aktivitas ini menggambarkan kegiatan aktor dalam melakukan permintaan untuk meng-upload dokumen kepada pengguna sistem lain yang memiliki dokumen yang dibutuhkan. Aktor juga dapat meng-upload dokumen yang sesuai dengan daftar request yang telah ada. Aktor perlu login untuk dapat melakukan request.

Gambar 4.8 Activity Diagram Request Dokumen

122 e. Upload Dokumen

Aktivitas ini menggambarkan kegiatan meng-upload dokumen ke sistem yang dilakukan oleh aktor. Aktor perlu login untuk melakukan aktivitas ini.

Gambar 4.9 Activity Diagram Upload Dokumen

123 f. Validasi Dokumen

Aktivitas ini menggambarkan kegiatan aktor dalam memvalidasi dokumen yang sesuai dan pantas untuk dimasukkan dan disimpan ke dalam sistem. Aktor hanya perlu mengganti status dokumen menjadi

‘valid’ apabila dokumen sesuai. Aktor perlu login ke dalam sistem untuk dapat melakukan aktivitas ini.

Gambar 4.10 Activity Diagram Validasi Dokumen

124 g. Login

Aktivitas ini menggambarkan kegiatan yang dilakukan oleh aktor untuk bisa masuk ke dalam sistem dan mendapatkan hak akses. Aktor harus memiliki email dan password untuk dapat masuk ke dalam sistem.

Gambar 4.11 Activity Diagram Login

125 h. Edit Profil

Aktivitas ini menggambarkan kegiatan aktor untuk mengubah data profil miliknya sendiri. Untuk dapat melakukan aktivitas ini aktor terlebih dahulu harus login ke dalam sistem.

Gambar 4.12 Activity Diagram Edit Profil

126 i. Logout

Aktivitas ini menggambarkan kegiatan aktor untuk keluar dari sistem. Aktor terlebih dahulu harus login ke dalam sistem.

Gambar 4.13 Activity Diagram Logout

j. Komentar

Aktivitas ini menggambarkan kegiatan aktor untuk mengelola komentar mulai dari menambahkan, mengedit, dan menghapus komentar. Untuk dapat mengelola komentar aktor terlebih dahulu harus login ke dalam sistem.

127 Gambar 4.14 Activity Diagram Komentar

k. Forum Diskusi

Aktivitas ini menggambarkan kegiatan aktor dalam mengelola forum diskusi mulai dari bergabung ke dalam forum, membuat forum diskusi baru, mengedit, menutup, hingga menghapus forum diskusi

128 yang telah dibuat. Masing-masing pengguna hanya mampu membuat satu buah forum diskusi. Aktor harus login ke dalam sistem terlebih dahulu untuk dapat melakukan aktivitas ini.

Gambar 4.15 Activity Diagram Forum Diskusi l. Manajemen User

Aktivitas ini menggambarkan kegiatan aktor atau dalam hal ini khusus administrator, untuk dapat mengelola seluruh user yang dapat

129 mengakses sistem. Aktor dapat mengedit dan menghapus user. Aktor harus login ke dalam sistem terlebih dahulu untuk menjalankan aktivitas ini.

Gambar 4.16 Activity Diagram Manajemen User

130 m. Registrasi User

Aktivitas ini menggambarkan kegiatan aktor yang dalam hal ini hanya dapat dilakukan oleh administrator, untuk dapat menambahkan seluruh user yang nantinya akan memiliki hak akses di dalam sistem.

Aktor diwajibkan login ke dalam sistem terlebih dahulu untuk bisa menambahkan user baru.

Gambar 4.17 Activity Diagram Registrasi User

131 4.2.2 Perancangan Database

4.2.2.1 Class Diagram

a) Menemukan Potential Object

Potential object yang dapat ditemukan berdasarkan pemaparan narasi use case diatas adalah sebagai berikut :

Tabel 4.18 Daftar Potential Object Login

Langkah selanjutnya dilakukan analisis untuk memilih objek-objek mana saja yang relevan dengan sistem akan dirancang sesuai dengan daftar potential object diatas.

132 Tabel 4.19 Daftar Analisa Potential Object

Potential Object Reason

Login X Tidak Relevan

Email X Bagian dari User

Password X Bagian dari User

User ✓ Ditulis User

Administrator X Bagian dari User Kepala UPTD X Bagian dari User

Karyawan X Bagian dari User

Dokumen ✓ Ditulis Dokumen

Download Dokumen X Bagian dari Dokumen Request Dokumen ✓ Ditulis Request Upload Dokumen X Bagian dari Dokumen Validasi Dokumen X Bagian dari Dokumen

Status ✓ Ditulis Status

Manajemen Dokumen X Bagian Dari Dokumen Form Tambah Dokumen X Tidak Relevan

Form Edit Dokumen X Tidak Relevan Hapus Dokumen X Tidak Relevan

Komentar Dokumen ✓ Ditulis Komentar Dokumen Komentar Request ✓ Ditulis Komentar Request

133

Forum ✓ Ditulis Forum

Buka Forum X Tidak Relevan

Tutup Forum X Tidak Relevan

Edit Forum X Bagian dari Forum

Tambah Forum X Bagian dari Forum

Diskusi ✓ Ditulis Diskusi

Tambah Diskusi X Bagian dari Diskusi

Edit user X Bagian dari User

Registrasi X Tidak relevan

Level ✓ Ditulis Level

Bidang ✓ Ditulis Bidang

Jabatan ✓ Ditulis Jabatan

Objek yang didapatkan terkait dengan sistem yang akan dirancang yaitu:

6) Komentar Dokumen

7) Forum 8) Diskusi 9) Request

10) Komentar Request 11) Status

134 c) Class Diagram

Berikut ialah class diagram yang menggambarkan struktur objek dari knowledge management system BAPPEDA.

Gambar 4.18 Class Diagram KMS BAPPEDA

135 4.2.2.2 Mapping Cardinality

Diagram ini menggambarkan relasi dari entitas-entitas pada class diagram untuk diubah kedalam tabel. Berikut adalah mapping dari knowledge management system BAPPEDA.

Gambar 4.19 Mapping Cardinality KMS BAPPEDA

136 4.2.2.3 Skema Database

Diagram ini menggambarkan model dari database dengan mendefinisikan struktur database dalam istilah tabel, keys, indeks, dan aturan-aturan integritasnya.

Gambar 4.20 Skema Database KMS BAPPEDA

137 4.2.2.4 Matriks CRUD

Matriks CRUD mengidentifikasikan hak akses masing-masing aktor terhadap entitas-entitas yang ada dalam database. Berikut adalah matriks CRUD dari knowledge management system BAPPEDA.

Tabel 4.20 Matriks CRUD KMS BAPPEDA Aktor

Entitas Admin Kepala UPTD Karyawan

users CRUD RU RU

user_id CR R R

email CRUD R R

nama_user CRUD RU RU

NIP CRUD R R

jenis_kelamin CRUD RU RU

tempat_lahir CRUD RU RU

tgl_lahir CRUD RU RU

no_hp CRUD RU RU

level_id CRUD R R

jabatan_id CRUD RU RU

bidang_id CRUD RU RU

password CRUD RU RU

foto CRUD RU RU

jabatans R R R

jabatan_id R R R

138

nama_jabatan R R R

levels R R R

level_id R R R

nama_level R R R

bidangs R R R

bidang_id R R R

nama_bidang R R R

documents CRUD CRUD CRUD

document_id CRD CRD CRD

nama_doc CRUD CRUD CRUD

file_doc CRUD CRUD CRUD

file_doc CRUD CRUD CRUD