commit to user
6
BAB II
LANDASAN TEORI
2.1 Konsep Dasar Sistem Informasi
Konsep dasar sistem informasi dibagi menjadi tiga bagian yaitu sistem, informasi dan sistem informasi itu sendiri. Menurut Mustakini (2001), sistem adalah kumpulan elemen-elemen yang saling berinteraksi satu sama lain untuk mencapai tujuan yang telah ditetapkan. Sebuah sistem terdiri dari bagian-bagian yang saling berkaitan yang beroperasi bersama untuk mencapai beberapa sasaran atau maksud, tujuan dan sasaran yang sama. Model umum suatu sistem terdiri dari
masukan (input), pengolah (process) dan keluaran (output).
Gambar 2.1 Model umum suatu sistem (Mustakini, 2001)
Informasi adalah data yang telah diolah menjadi sebuah bentuk yang berarti bagi penerimanya dan bermanfaat dalam pengambilan keputusan saat ini atau mendatang.
Menurut Nash dan Roberts dalam Mustakini (2001) bahwa sistem informasi merupakan suatu dari orang-orang fasilitas, teknologi, media, prosedur-prosedur dan pengendalian yang ditujukan untuk mendapatkan jalur komunikasi penting, memproses tipe transaksi rutin tertentu, memberi sinyal kepada manajemen dan yang lainnya terhadap kejadian-kejadian internal dan eksternal yang penting dan yang menyediakan suatu dasar untuk pengambilan keputusan yang cerdik.
Menurut Bower, Schlosser dan Newman dalam Mustakini (2001) bahwa sistem informasi adalah suatu cara yang sudah tertentu untuk menyediakan informasi yang dibutuhkan oleh organisasi untuk beroperasi dengan cara yang sukses dan untuk organisasi bisnis dengan cara yang menguntungkan.
OUTPUT PROCESS
commit to user
6
Keberhasilan suatu sistem informasi sangat bergantung pada basisdata. Semakin lengkap, akurat dan mudah dalam menampilkan kembali data yang ada dalam sistem basis data maka akan semakin tinggi kualitas sistem informasi tersebut.
Analisis dan perancangan sistem informasi adalah rangkaian proses yang dilakukan untuk memahami sistem yang berjalan, sedangkan implementasi sistem merupakan tahap yang dilakukan setelah perancangan sistem.
2.2 Rekayasa Perangkat Lunak
Menurut Sommerville (2003), Rekayasa Perangkat Lunak adalah disiplin ilmu yang membahas semua aspek produksi perangkat lunak, mulai dari tahap awal spesifikasi sistem sampai pemeliharaan sistem setelah digunakan.
Secara umum, perekayasa perangkat lunak memakai pendekatan yang sistematis dan terorganisir terhadap pekerjaan mereka karena cara ini seringkali paling efektif untuk menghasilkan perangkat lunak berkualitas tinggi. Namun demikian, rekayasa ini sebenarnya mencakup masalah pemilihan metode yang paling sesuai untuk satu set keadaan dan pendekatan yang lebih kreatif, informal terhadap pengembangan yang mungkin efektif pada beberapa keadaan.
Model proses perangkat lunak merupakan deskripsi yang disederhanakan dari proses perangkat lunak yang dipresentasikan dengan sudut pandang tertentu. Model, sesuai sifatnya, merupakan penyederhanaan, sehingga model proses perangkat lunak merupakan abstraksi dari proses sebenarnya yang dideskripsikan. Model proses bisa mencakup kegiatan yang merupakan bagian dari proses perangkat lunak, produk perangkat lunak, dan peran orang yang terlibat pada rekayasa perangkat lunak. Beberapa contoh jenis model proses perangkat lunak yang dapat dihasilkan di antaranya :
1. Model aliran kerja (workflow). Model ini menunjukkan urutan kegiatan pada
proses bersama dengan input, output, dan ketergantungan. Kegiatan pada model ini mempresentasikan pekerjaan manusia.
2. Model aliran data (data flow) atau kegiatan. Model ini merepresentasikan
commit to user
6
data. Model ini menunjukkan bagaimana input ke proses, misalnya spesifikasi, ditransformasi menjadi output, misalnya desain. Kegiatan di sini mungkin berada pada tingkat yang lebih rendah daripada kegiatan pada model aliran kerja. Model ini merepresentasikan transformasi yang dilakukan oleh orang atau komputer.
3. Model peran/aksi. Model ini merepresentasikan peran orang yang terlibat
pada proses perangkat lunak dan kegiatan yang menjadi tanggung jawab mereka.
2.3 UML
Menurut Pender (2002), UML adalah standar untuk menciptakan model yang mewakili perangkat lunak berorientasi objek dan sistem bisnis. UML memiliki standarisasi notasi tetapi tidak mendikte bagaimana menerapkan notasi. UML mencakup spesifikasi untuk sembilan diagram berbeda yang digunakan untuk berbagai dokumen perspektif dari solusi perangkat lunak dari awal proyek sampai instalasi dan pemeliharaan mikrofinansial.
Salah satu cara untuk mengatur diagram UML adalah dengan menggunakan
view. View adalah kumpulan diagram yang menggambarkan aspek yang sama dari
proyek. View mempunyai 3 pelengkap, yaitu Static View, Dynamic View, dan
Functional View.
a. Static View
Static View termasuk diagram yang memberikan gambaran dari unsur-unsur
dari sistem tetapi tidak memberitahu bagaimana elemen akan berperilaku. Hal ini
sangat mirip Blueprint. Blueprint itu komprehensif, tetapi mereka hanya
menunjukkan apa yang tetap diam, maka disebut Static View. Static View
commit to user
6
b. Dynamic View
Pada Dynamic View meliputi diagram yang mengungkapkan bagaimana
benda berinteraksi dengan satu sama lain dalam respon terhadap lingkungan. Ini
termasuk Sequence Diagram dan Collaboration Diagram, yang kolektif disebut
sebagai diagram interaksi. Mereka secara khusus dirancang untuk menjelaskan
bagaimana benda berbicara satu sama lain. Ini juga mencakup Statechart
Diagram, yang menunjukkan bagaimana dan mengapa perubahan objek dari waktu ke waktu dalam menanggapi lingkungan.
c. Functional View
Functional View terbentuk oleh Use Case Diagram dan Activity Diagram.
Use Case Diagram
Menggambarkan fitur di mana pengguna mengharapkan sistem untuk
menyediakan. Lima elemen pemodelan yang membentuk Use Case Diagram:
actor, Use Case, association, dan dependency.
Tabel 2.1 Simbol Use Case Diagram (Pender, 2002)
Simbol Keterangan
Actor; Sebuah peran yang dimainkan oleh seseorang, sistem, atau perangkat yang memiliki saham dalam keberhasilan operasi dari sistem.
Use Case; Untuk mengungkapkan tujuan bahwa sistem harus dicapai.
Association; Mengidentifikasi interaksi antara aktor dan
commit to user
6
Dependency; Mengidentifikasi hubungan komunikasi antara dua Use Case.
Activity Diagram
Diagram ini menggambarkan proses yang termasuk tugas berurutan, logika kondisional, dan konkurensi. Diagram ini adalah seperti flowchart, tetapi telah ditingkatkan untuk digunakan dengan pemodelan objek.
Tabel 2.2 Simbol Activity Diagram (Pender, 2002)
Class Diagram
Kelas Diagram terdiri dari tiga kompartemen (ruang persegi panjang) yang mengandung informasi yang berbeda diperlukan untuk menjelaskan sifat-sifat satu jenis objek.
Class Name Attribute Operations()
commit to user
6
Notasi dalam class diagram adalah sebagai berikut :
1. Class Name digunakan untuk mendefinisikan class (tipe objek) dalam sebuah
paket.
2. Attribute berisi semua definisi data.
3. operations berisi definisi untuk setiap perilaku yang didukung oleh jenis
objek.
Sequence Diagram
Semua Sequence diagram lebih dimodelkan pada tingkat objek daripada
tingkat kelas untuk memungkinkan skenario yang menggunakan lebih dari satu instance dari kelas yang sama dan bekerja pada tingkat fakta, data uji, dan contoh.
Sequence Diagram menggunakan tiga elemen notasi mendasar: object, message/stimuli, and object lifeline.
Tabel 2.3 Simbol Sequence Diagram (Pender, 2002)
Simbol Keterangan
Objects; mewakili peserta
Messages/Stimuli; mewakili komunikasi yang dikirim satu sama lain.
Lifeline; untuk mengatur pesan-pesan dalam urutan yang relatif tepat.
commit to user
6
2.4 Web Service
Menurut Snell (2001), Sebuah Web Service adalah antarmuka jaringan yang dapat diakses untuk fungsionalitas aplikasi, dibangun dengan menggunakan standard teknologi Internet. Dengan kata lain, jika sebuah aplikasi dapat diakses melalui jaringan menggunakan kombinasi dari protokol seperti HTTP, XML, SMTP, atau Jabber, maka itu adalah Web Service. Meskipun semua media hype sekitar web service, itu benar-benar sederhana. Web service bukanlah hal yang baru. Sebaliknya, web service mewakili evolusi prinsip-prinsip yang telah membimbing internet selama bertahun-tahun.
XML memungkinkan pengembang software untuk meng-expose sumber daya berharga pada bentuk yang memilki interoperabilitas tinggi, dimana sumber daya ini adalah semua tipe aplikasi atau pnyimpanan data yang digunakan oleh antar organisasi. Arsitektur XML Web services mendefinisikan mekanisme standard untuk menyediakan sumber daya melalui pengiriman pesan XML. Untuk mengakses sumber daya hanya dengan mentransmisikan pesan-pesan XML
melalui protokol standard seperti TCP, HTTP, atau SMTP. Kata “Web Service”
mengacu pada bagian kode yang mengimplementasikan interface XML menjadi sumber daya, dimana bias jadi sulit diakses.
Sebuah web service adalah sebuah antarmuka diposisikan antara kode aplikasi dan pengguna dari kode tersebut. Ini bertindak sebagai lapisan abstraksi, memisahkan platform dan bahasa pemrograman-spesifik rincian tentang bagaimana kode aplikasi sebenarnya dipanggil. Lapisan standar berarti bahwa setiap bahasa yang mendukung web service dapat mengakses fungsionalitas aplikasi.
Saat ini ada dua sekolah pemikiran dalam mengembangkan web service : pendekatan berbasis standar (SOAP) serta konseptual yang sederhana dan trendi (REST). Keputusan antara dua akan menjadi pilihan pertama dalam merancang web service, sehingga sangat penting untuk memahami pro dan kontra dari keduanya. Hal ini juga penting, dalam perdebatan yang kadang-kadang panas antara dua filosofi untuk memisahkan kenyataan dari retorika.
commit to user
6
SOAP "Simple Object Access Protocol" dirancang untuk menjadi alternatif platform dan bahasa-netral untuk techologies middleware sebelumnya seperti CORBA dan DCOM. Penampilan publik pertama adalah publik draft Internet (diserahkan ke IETF) pada tahun 1999; lama kemudian, pada bulan Desember 1999, SOAP 1.0 dirilis. Pada bulan Mei tahun 2000 versi 1.1 diserahkan kepada W3C mana ia membentuk jantung dari teknologi Web Services yang muncul. Versi saat ini adalah 1,2, diselesaikan pada tahun 2005.
Posisi SOAP dalam tumpukan teknologi web service sebagai protokol standar untuk kemasan pesan bersama oleh aplikasi. Spesifikasi ini mendefinisikan tidak lebih dari sebuah amplop berbasis XML sederhana untuk informasi yang ditransfer, dan satu set aturan untuk menerjemahkan aplikasi dan platform yang spesifik tipe data ke dalam representasi XML. Desain SOAP membuatnya cocok untuk berbagai macam aplikasi pesan dan pola integrasi. Hal ini untuk sebagian besar memberikan kontribusi untuk popularitas berkembang.
Gambar 2.3 SOAP-XML (Snell, 2001)
Menurut Fielding (2002), REST adalah seperangkat terkoordinasi kendala arsitektur yang mencoba untuk meminimalkan latency dan jaringan komunikasi, sementara pada saat yang sama memaksimalkan kemandirian dan skalabilitas dari implementasi komponen. Hal ini dicapai dengan menempatkan kendala pada semantik konektor, di mana gaya lain telah berfokus pada komponen semantik. REST memungkinkan caching dan penggunaan kembali interaksi, dinamis substitusi komponen, dan pengolahan tindakan oleh perantara, dalam rangka memenuhi kebutuhan sistem hypermedia internet skala didistribusikan.
commit to user
6
Web modern adalah salah satu contoh dari arsitektur REST-style. Meskipun aplikasi berbasis web dapat mencakup akses ke gaya lain dari interaksi, fokus sentral dari keprihatinan protokol dan kinerja didistribusikan hypermedia.
REST menguraikan hanya bagian dari arsitektur yang dianggap penting untuk Internet-skala interaksi hypermedia didistribusikan. Daerah untuk perbaikan arsitektur Web dapat dilihat di mana protokol yang ada gagal untuk mengekspresikan semua potensi interaksi semantik komponen, dan di mana rincian sintaks dapat diganti dengan bentuk yang lebih efisien tanpa mengubah kemampuan arsitektur. Demikian pula, ekstensi yang diusulkan dapat dibandingkan REST untuk melihat apakah mereka cocok dalam arsitektur; jika tidak, biasanya lebih efisien untuk mengarahkan fungsi yang untuk sistem berjalan secara paralel dengan gaya arsitektur yang lebih berlaku.
commit to user
15
BAB III
ANALISIS KEBUTUHAN DAN PERANCANGAN SISTEM
3.1 Deskripsi Umum Sistem
Perancangan sistem sangat dibutuhkan sebelum membuat suatu aplikasi.
Rancangan tersebut meliputi perancangan input dan output. Untuk memahami dan
merealisasikan sistem, diperlukan suatu gambaran mengenai sistem alur data yang terjadi.
Sistem Informasi Sumber Daya berbasis Data Monografi adalah suatu aplikasi berbasis web yang memfasilitasi Kecamatan Colomadu dalam melakukan pengarsipan administrasi desa sebagai pengganti proses pengarsipan administraasi desa dengan media buku. Dengan demikian diharapkan akan menjadi lebih efektif dalam pengaplikasiannya.
Sistem Informasi Sumber Daya berbasis Data Monografi ini juga
menggunakan sistem komunikasi berbasis web service. Kegunaan web service ini
untuk menghubungkan antara 2 sistem yang berbeda, yaitu sistem untuk user dan sistem untuk pengunjung. Sehingga keamanan data terjaga dengan baik.
Sistem Informasi Sumber Daya berbasis Data Monografi ini dirancang menggunakan visualisasi model UML dimana visualisasi tersebut diperuntukan model sistem yang Objek Oriented Programming.
Dari deskripsi di atas, akan dijabarkan lebih spesifik pada tahap analisis dan perancangan untuk menguraikan sub-sub bagian dan visualisasi dari sistem yang akan digunakan untuk tahap implementasi (pembuatan) sistem.
Gambar 3.1 Implementasi Web Service
Aplikasi User Web Service Aplikasi Pengunjung
commit to user
3.2 Analisis Kebutuhan
a. Kebutuhan Fungsional
Tabel 3.1 Kebutuhan fungsional sistem
Kode Deskripsi Level
FSIM-01 Sistem menyediakan fungsi login Operator Kelurahan,
Admin Kecamatan, Kepala Desa, Admin Kabupaten FSIM-02 Sistem menyediakan fungsi menambah
data monografi
Admin Kelurahan
FSIM-03 Sistem menyediakan fungsi melihat data monografi
Operator Kelurahan, Admin Kecamatan, Admin Kabupaten, Kepala Desa FSIM-04 Sistem menyediakan fungsi menghapus
data monografi
Operator Kelurahan
FSIM-05 Sistem menyediakan fungsi menambah notifikasi
Admin Kecamatan, Kepala Desa
FSIM-06 Sistem menyediakan fungsi melihat
notifikasi
Operator Kelurahan
FSIM-07 Sistem menyediakan fungsi validasi Kepala Desa
FSIM-08 Sistem menyediakan fungsi verifikasi Admin Kecamatan
FSIM-09 Sistem menyediakan fungsi menambah data kelurahan
Admin Kecamatan
FSIM-10 Sistem menyediakan fungsi merubah data kelurahan
Admin Kecamatan
FSIM-11 Sistem menyediakan fungsi melihat data kelurahan
Admin Kecamatan, Admin Kabupaten FSIM-12 Sistem menyediakan fungsi menambah
data user
commit to user
FSIM-13 Sistem menyediakan fungsi merubah data user
Admin Kabupaten
FSIM-14 Sistem menyediakan fungsi melihat data user
Admin Kabupaten
b. Kebutuhan Non Fungsional
Tabel 3.2 Kebutuhan Non fungsional sistem
Kode Deskripsi
NFSIM-01 Sistem harus dapat mengurangi transaksi manual
NFSIM-02 Sistem harus dapat digunakan diseluruh lokasi
3.3 Perancangan Sistem
a. Aktor
1. Deskripsi Aktor
Tabel 3.3 Deskripsi Aktor
Nama Deskripsi
Operator Kelurahan Adalah orang yang bertanggung jawab untuk mengelola
data monografi pada kelurahan terkait
Admin Kecamatan Adalah orang yang bertanggung jawab untuk
memverifikasi data monografi yang diterima serta mengelola data kelurahan.
Kepala Desa Adalah orang yang bertanggung jawab untuk
mem-validasi data yang akan di kirim ke kecamatan
commit to user
2. Hak dan Kewajiban Aktor
Tabel 3.4 Hak dan Kewajiban Aktor
Nama Deskripsi
Operator Kelurahan Melakukan pengelolaan data monografi seperti
menambah dan merubah.
Admin Kecamatan Melakukan verifikasi data monografi yang diterima dan
melakukan pengelolaan data kelurahan, seperti
menambah dan merubah.
Admin Kabupaten Melakukan pengelolaan data user seperti menambah dan
merubah
Kepala Desa Melakukan validasi atas data yang akan dikirim ke
kecamatan.
b. Use Case
1. Deskripsi Use Case
Tabel 3.5 Deskripsi Use Case
Nama Deskripsi
Login Fungsi untuk memberikan hak akses kepada user
Menambah Monografi Fungsi untuk menambahkan data monografi
Melihat Monografi Fungsi untuk melihat data monografi
Menghapus Monografi Fungsi untuk menghapus data monografi
Menambah User Fungsi untuk menambah data user
Merubah User Fungsi untuk merubah data user
Melihat User Fungsi untuk melihat data user
Menambah Kelurahan Fungsi untuk menambah data kelurahan
Merubah Kelurahan Fungsi untuk merubah data kelurahan
Melihat Kelurahan Fungsi untuk melihat data kelurahan
Validasi Data Fungsi untuk mem-validasi data yang akan dikirim
commit to user
Menambah Notifikasi Fungsi untuk membuat notifikasi untuk diberikan
kepada operator kelurahan
20
15
2. Diagram Use Case
Gambar 3.2 Diagram Use Case Operator Kelurahan
Admin Kabupaten
login menambah data monografi
menampilkan data monografi
menghapus data monografi
Admin Kecamatan
verifikasi data monografi Kepala Desa
memperbarui data user validasi data monografi
menambah data user
<<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<extend>> <<include>> membuat notifikasi <<include>> Pengunjung
menambah data kelurahan
merubah data kelurahan <<include>>
<<extend>>
<<include>> menampilkan data kelurahan
<<extend>>
<<include>> menampilkan notifikasi
commit to user
15
c. Diagram Activity
1. Login
Gambar 3.3 Diagram Activity Login
2. Menambah Data User
Gambar 3.4 Diagram Activity Menambah Data User get username dan password
cek database
Found ?
No
Yes
get username, password, id_level
cek database
Valid ?
No
simpan username, password, id_level Yes
commit to user
3. Merubah Data User
Gambar 3.5 Diagram Activity Merubah Data User
4. Melihat Data User
Gambar 3.6 Diagram Activity Melihat Data User get username
cek database
Valid ?
menampilkan data user
get Username, Password baru
ubah password = password baru Yes
No
get username
commit to user
5. Menambah Data Monografi
Gambar 3.7 Diagram Activity Menambah Data Monografi
6. Menghapus Data Monografi
Gambar 3.8 Diagram Activity Menghapus Data Monografi
get Data Monografi
cek database
Valid ?
No
simpan data monografi Yes
get id_periode
commit to user
7. Melihat Data Monografi
Gambar 3.9 Diagram Activity Melihat Data Monografi
8. Menambah Data Kelurahan
Gambar 3.10 Diagram Activity Menambah Data Kelurahan get id_periode
menampilkan data monografi
get kd_kelurahan, nm_kelurahan
cek database
Valid ?
No
simpan kd_kelurahan, nm_kelurahan Yes
commit to user
9. Merubah data Kelurahan
Gambar 3.11 Diagram Activity Merubah Data Kelurahan
10.Melihat Data Kelurahan
Gambar 3.12 Diagram Activity Melihat Data Kelurahan get kd_kelurahan, nm_kelurahan
cek database
Valid ?
No get kd_kelurahan
menampilkan data kelurahan
ubah kelurahan = kelurahan baru Yes
get kd_kelurahan
commit to user
11.Validasi Data, Verifikasi Data, dan Membuat Notifikasi
Gambar 3.13 Diagram Activity Validasi Data, Verifikasi Data dan Membuat Notifikasi
12.Melihat Notifikasi
Gambar 3.14 Diagram Activity Melihat Notifikasi get id_periode
menampilkan data monografi
Accept ? get notifikasi
Yes No get status
cek database valid ?
No
simpan notifikasi Yes
get id
commit to user
d. Perancangan Antarmuka
1. Login
Gambar 3.15 Perancangan Antarmuka Login
2. Menambah Data User
Gambar 3.16 Perancangan Antarmuka Menambah Data User
3. Merubah Data User
Gambar 3.17 Perancangan Antarmuka Merubah Data User
4. Melihat Data User
commit to user
5. Menambah Data Monografi
Gambar 3.19 Perancangan Antarmuka Menambah Data Monografi
6. Menghapus Data Monografi
Gambar 3.20 Perancangan Antarmuka Menghapus Data Monografi
7. Melihat Data Monografi
Gambar 3.21 Perancangan Antarmuka Melihat Data Monografi
8. Menambah Data Kelurahan
commit to user
9. Merubah Data Kelurahan
Gambar 3.23 Perancangan Antarmuka Merubah Data Kelurahan
10.Melihat Data Kelurahan
Gambar 3.24 Perancangan Antarmuka Melihat Data Kelurahan
11.Validasi Data
Gambar 3.25 Perancangan Antarmuka Validasi Data
12.Verifikasi Data
commit to user
13.Menambah Data Notifikasi
Gambar 3.27 Perancangan Antarmuka Menambah Data Notifikasi
14.Melihat Data Notifikasi
commit to user
e. Diagram Sequence
1. Login
Gambar 3.29 Diagram Sequence Login
2. Menambah Data User
Gambar 3.30 Diagram Sequence Menambah Data User
: login <<boundary>> : UserIdentify <<control>> : User <<entity>> : User 1 : setUsername()
2 : username:=getUsername() 3 : username := getUsername() 4 : authenticate() 5 : displayMessage() 6 : setPassword() 7 : password:=getPassword() 8 : authenticate() 9 : displayMessage() 10 : id := getLevelId() 11 : authenticate() 12 : displayMessage() : Admin Kabupaten : UserController <<control>> : User <<entity>> : CreateUser <<boundary>>
1 : memasukkan data user
2 : getUser() 3 : return data user
4 : getTable()
5 : return table 6 : actionCreate() 7 : menampilkan pesan
commit to user
3. Merubah Data User
Gambar 3.31 Diagram Sequence Merubah Data User
4. Melihat Data User
Gambar 3.32 Diagram Sequence Melihat Data User
: Admin Kabupaten : User
<<entity>> : UserController <<control>> : UpdateUser <<boundary>> 1 : memilih username 2 : getUsername() 3 : return username 4 : getTable() 5 : return tabel 6 : displayData()
7 : memasukkan data user terbaru
8 : getUser() 9 : return data user
10 : getTable() 11 : return tabel 12 : actionUpdate() 13 : displayMessage() : Admin Kabupaten : UserController <<control>> : User <<entity>> : ViewUser <<boundary>> 1 : memilih username 2 : getUsername() 3 : return username 4 : getTable() 5 : return table 6 : actionView() 7 : displayData()
commit to user
5. Menambah Data Monografi
Gambar 3.33 Diagram Sequence Menambah Data Monografi
6. Menghapus Data Monografi
Gambar 3.34 Diagram Sequence Menghapus Data Monografi
7. Melihat Data Monografi
Gambar 3.35 Diagram Sequence Melihat Data Monografi
: Operator Kelurahan : MonografiController <<control>> : Monografi <<entity>> : CreateMonografi <<boundary>>
1 : memasukkan data monografi
2 : getData() 3 : return data monografi
4 : getTable() 5 : return table 6 : actionCreate() 7 : diplayMessage() : Operator Kelurahan : DeleteMonografi <<boundary>> : MonografiController <<control>> : Monografi <<entity>> 1 : memilih id_periode 2 : getIdPeriode() 3 : return id_periode 4 : getTable() 5 : return table 6 : actionDelete() 7 : displayMessage() : User : ViewMonografi <<boundary>> : MonografiController <<control>> : Monografi <<entity>>