commit to user 10
1. Waktu pembuatan aplikasi jauh lebih singkat. 2. Kode aplikasi menjadi lebih mudah dibaca, karena sedikit dan sifatnya
pokok. Detailnya adalah kode dari framework itu sendiri yang sudah terjamin.
3. Aplikasi menjadi lebih mudah untuk diperbaiki, karena tidak perlu fokus ke semua komponen kode, terutama kode sistem framework tersebut.
4. Tidak perlu membuat kode penunjang aplikasi seperti koneksi database, form, GUI, keamanan dan lain sebagainya karena sudah disediakan oleh
framework. 5. Pemrograman menjadi lebih terfokus pada alur aplikasi seperti apa yang
akan ditampilkan dan layanan apa saja yang akan diberikan oleh aplikasi. 6. Jika proyek dikerjakan secara team work, maka akan lebih terarah karena
sistem framework mengharuskan adanya keteraturan peletakan kode. Sehingga tim hanya akan berfokus pada bidang kerjanya masing-masing.
2.6 MVC Model-View-Controller
MVC adalah kaidah pemrograman yang digunakan berdasarkan konsep tim pengembang yang memungkinkan pemisahan antara layer application-logic
dan presentation. Sehingga apabila diaplikasikan dalam sebuah tim, seorang programmer bisa berkonsentrasi pada core-system dan seorang web desaigner
bisa berkonsentrasi pada sisi tampilan. Dengan demikian aplikasi yang dibuat akan mudah untuk di-maintenance dan dikembangan lebih lanjut Basuki, 2010.
Secara spesifik konsep MVC dapat digambarkan sebagai berikut.
Gambar 2.2 Konsep MVC
commit to user 11
Ketika datang user request, maka permintaan tersebut akan ditangani oleh Controller, kemudian Controller akan memanggil Model jika memang diperlukan
operasi database. Hasil dari query oleh Model selanjutnya akan dikembalikan kepada Controller. Kemudian Controller akan memanggil View yang tepat dan
mengkombinasikannya dengan hasil query Model. Hasil akhir dari operasi ini akan ditampilkan ke browser yang selanjutnya dilihat oleh user. Keterangan dari
masing-masing Model-View dan Controller adalah sebagai berikut. 1. Model : Kode program berupa OOP class yang digunakan untuk
memanipulasi database 2. View : Berupa template htmlxhtmlphp yang digunakan untuk menampilkan
data pada browser 3. Controller : Kode program berupa OOP class yang digunakan untuk
mengontrol aliran aplikasi pengontrol antara Model dan View
2.7 Pemodelan Sistem
UML Pender, 2002 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 dibentuk oleh dua diagram, yaitu Class Diagram dan Object Diagram.
commit to user 12
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.
1 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 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 Use Case
Dependency; Mengidentifikasi hubungan komunikasi antara dua Use Case.
2 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.
commit to user 13
Gambar 2.3 Simbol Activity Diagram
3 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
Gambar 2.4 Notasi Class Diagram Notasi dalam class diagram adalah sebagai berikut :
a. Class Name digunakan untuk mendefinisikan class tipe objek dalam sebuah paket.
b. Attribute berisi semua definisi data. c. Operations berisi definisi untuk setiap perilaku yang didukung oleh jenis
objek.
commit to user 14
Tabel 2.2 Simbol Class Diagram Simbol
Keterangan Bondary
Class atau
kelas pembatas merupakan class yang
menyalurkan interaksi
antara sistem dengan dunia sekitarnya.
Kelas ini biasanya digunakan untuk menangani informasi yang
mungkin akan selalu disimpan dalam proses bisnis.
Kelas ini
bersifat opsional,
apabila kelas ini digunakan maka satu kelas control untuk satu use
case yang digunakan mengatur kejadian dalam use case tersebut.
4 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, messagestimuli, and object lifeline.
Tabel 2.3 Simbol Sequence Diagram Simbol
Keterangan Objects; mewakili peserta
MessagesStimuli; mewakili komunikasi yang dikirim satu sama lain.
Lifeline; untuk mengatur pesan-pesan dalam urutan yang relatif tepat.
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.
Aplikasi Arsip di UPT Puskom UNS adalah suatu aplikasi berbasis web yang memfasilitasi UPT Puskom UNS dalam melakukan surat menyurat
elektronis sebagai pengganti proses surat menyurat dengan media kertas. Dengan demikian diharapkan akan menjadi lebih efektif dalam pengaplikasiannya.
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.
3.2 Analisis Kebutuhan
3.2.1 Kebutuhan Fungsional
Tabel 3.1 Kebutuhan Fungsional Sistem
Kode Deskripsi
Aktor
F1 Dapat login sebelum mengakses sistem
Personal, admin F2
Dapat menulis pesan personal
F3 Dapat melihat surat masuk sesuai dengan hak akses
personal F4
Dapat melihat surat keluar sesuai dengan hak akses personal
F5 Dapat memforward surat masuk
personal F6
Dapat memforward surat keluar personal
F7 Dapat menyimpan surat
personal F8
Dapat mengirim surat personal
F9 Dapat melihat draft surat
personal F10
Dapat mengedit draft surat personal
