Download - Rayzameel Muhammad
Perancangan Sistem Informasi“Studi Kasus Sistem Terstruktur dan Sistem Berbasis Web”
Universitas Muhammadiyah Cirebon
Disusun Oleh :
Muhammad Rae Jamil 100511025
Jl. Tuparev No: 70, Cirebon, Website : www.umc.ac.id
2012
KATA PENGANTAR
Alhamdulillah, puji syukur kita panjatkan kehadirat Allah S.W.T, karena berkat rahmat-Nya makalah ini dapat kami selesaikan susai dengan yang diharapkan. Kami juga bersyukur atas rizki dan kesehatan yang diberikan-Nya sehingga kami dapat mengumpulkan bahan-bahan materi makalah dari buku dan internet.
Makalah ini disusun untuk diajukan sebagai salah satu tugas mata kuliah Teori Belajar Dan Pembelajaran dengan judul “STUDI KASUS TENTANG PERMODELAN SISTEM TERSTRUKTUR DAN PERMODELAN SISTEM BERBASIS WEB (UML)”. Makalah ini diharapkan agar pembaca dapat memahami isi dari makalah, sehingga pembaca dapat mengembangkan wawasan pengetahuan pembaca.
Kami mengakui bahwa dalam menyusun makalah ini tidak dapat diselesaikan tanpa adanya bantuan dari berbagai pihak. Pada kesempatan ini, kami mengucapkan terima kasih kepada:1. Ibu Dian Novianty, M.Kom.
Selaku dosen mata kuliah Perancangan Sistem Informasi di Universitas Muhammadiyah Cirebon,
2. Rekan – rekan semua, dan 3. Keluarga.
Dalam penyusunan makalah ini kami merasa masih ada banyak kekurangannya, maka dari itu dengan segala kerendahan hati kami mohon pembaca dapat memakluminya. Semoga makalah ini dapat memberikan informasi bagi pembaca dan bermanfaat untuk pengembangan ilmu pengetahuan bagi kita semua. Kritik dan saran setia kami nantikan demi perbaikan selanjutnya.
Cirebon, 17 Juni 2012
Penyusun
DAFTAR ISI
KATA PENGANTAR ………………………………………………………………………………………………………… i
DAFTAR ISI …………………………………………………………………………………………………………………….. ii
BAB I PENDAHULUAN ……………………………………………………………………………………………………. 1
A. Latar Belakang ……………………………………………………………………………………………… 1B. Rumusan Masalah ……………………………………………………………………………………….. 1C. Tujuan …………………………………………………………………………………………………………. 1
BAB II PEMBAHASAN …………………………………………………………………………………………………….. 2
A. Pemodelan Sistem tertsruktur ……………………………………………………………………… 2B. Pemodelan Sistem Berbasis WEB (UML) ………………………………………………………. 12
BAB III PENUTUP ……………….................................................................................................. 22
A. Kesimpulan ………………………………………………………………………………………………..... 22
DAFTAR PUSTAKA …………………………………………………………………………………………………………. 23
BAB I
PENDAHULUAN
A. Latar Belakang
Dalam mendesain suatu system terdapat banyak cara
permodelan sistem. Namun dalam pembahasan kali ini kami hanya
mengambil 2 cara permodelan system, yaitu permodelan system
terstruktur dan permodelan system berbasis WEB (UML). Dimana
dalam pembahasan kali ini kami akan membahas tentang pengertian,
tujuan, dll. Sehingga dapat membandingkan mana permodelan yang
akan digunakan.
Dari latar belakang diatas, maka kami akan mengambil sebuah
judul yaitu “STUDI KASUS TENTANG PERMODELAN SISTEM
TERSTRUKTUR DAN PERMODELAN SISTEM BERBASIS WEB (UML)”
B. Rumusan Masalah
1. Bagaimana pemodelan sistem terstruktur pada sistem perhotelan?
2. Bagaimana pemodelan sistem berbasis WEB (UML) pada sistem
parkir?
C. Tujuan
1. Mengetahui pemodelan sistem terstruktur pada sistem perhotelan.
2. Mengetahui pemodelan sistem berbasis WEB (UML) pada sistem
parkir.
BAB II
PEMBAHASAN
A. Pemodelan Sistem Terstruktur
Pemodelan terstruktur digunakan dalam analisis sistem, rancangan
sistem, dan pengembangan perangkat lunak. Pada dasarnya
merupakan pemodelan dengan pendekatan yang baku dan sistematik
dengan menerapkan tahapan-tahapan yang sistematik dan bertujuan
agar diperoleh hasil berupa suatu informasi yang bermanfaat dan
memenuhi kebutuhan pemakai. Pemodelan ini merupakan pemodelan
yang sudah lama dipakai. Namun dalam perkembangan pemodelan
munculah pemodelan-pemodelan lain
Berikut adalah studi kasus Pemodelan Sistem Terstruktur pada Jasa
Pelayanan Hotel :
A. Bagan berjenjang / HIPO
B. Diagram Konteks
C. DFD Level 0
D. DFD Level 1
Check-In
Order Fasilitas
Check-Out
Pembuatan Laporan
Pembuatan Laporan Keuangan
Input Data Tamu
Sistem Informasi Jasa Pelayanan Hotel
Check In Penggunaan Fasilitas Check Out Pembuatan Laporan
Input Order Fasilitas
Cetak Kartu Tamu
Hitung dan Cetak BillInput Bill Fasilitas
Hitung Bill PembayaranCetak Bukti PembayaranPembayaran
Pembuatan Laporan Daftar Tamu
Bagan Berjenjang / Hirarchy DiagramHirarchy Diagramel 1 Check In
Sistem Informasi Jasa Pelayanan Hotel
Tamu
Bag. Fasilitas Bag. Fasilitas
Identitas, Order Fasilitas, Bill PembayaranKartu Tamu, Bill Pembayaran, Bukti Pembayaran
Bill Fasilitas
Daftar Tamu, Order Fasiltas Lap. Keuangan & Lap. Pendaftaran Tamu
2. Diagram Konteks
3. DFD Level 0
1.0 Check In
2.0 Penggunaan Fasilitas
3.0 Check Out
4.0 Pembuatan Laporan
Tamu
Identitas Tamu
Kartu Tamu
Bill Pembayaran
Bill Pembayaran, Bukti Pembayaran
Order FasilitasTamu
Fasilitas Transaksi Inap
Bag. Fasilitas
Transaksi Fasilitas
Manager
Tamu
Bill Fasilitas Order Fasilitas Lap. KeuanganLap. Pendaftaran Tamu
Daftar Tamu
4. DFD Level 1 Check InTamu
1.1Input Data Tamu
Tamu
Bag. Fasilitas
1.2Cetak Kartu Tamu
Identitas Tamu Kartu Tamu
Daftar Tamu
5. DFD Level 1 Order Fasilitas
Tamu
2.1Input Order Fasilitas
Fasilitas 2.3Input Bill Fasilitas
2.2Hitung & Cetak Bill
Transaksi Fasilitas
3.1Perhitungan Bill Pembayaran
3.3Pembayaran
3.2Cetak Bukti Pembayaran
Transaksi Fasilitas
Transaksi Inap
TamuTamu
Bill Pembayaran
Bill Pembayaran
Bukti Pembayaran
6. DFD Level 1 Check Out
4.1Perhitungan Bill Pembataran
4.2Perhitungan Bill Pembataran
Transaksi Inap
7. DFD Level 1 Pembuatan Laporan
Tamu
Manager
Lap. Pendaftaran Tamu Lap. Keuangan
Tamu Front Office Bag. Fasilitas
Identitas Tamu Identitas Tamu
Daftar Tamu
Kartu Tamu
Input Data Tamu
Tamu
Pencetakan Kartu Tamu dan Daftar
Tamu
Kartu Tamu
Arsip
Daftar Tamu
8. Flowchart Check-In
Tamu Bag. Fasilitas Front Office
Order Fasilitas Order Fasilitas
Input Data Tamu
Transaksi Fasilitas
Fasilitas
Hitung & Cetak Bill Fasilitas
Bill Fasilitas Bill Fasilitas
Input Bill Fasilitas
Transaksi Inap
9. Flowchart Order Fasilitas
Bukti Pembayaran
Transaksi InapTransaksi Fasilitas
Bill Pembayaran
Perhitungan Bill Pembayaran
Bill Pembayaran
Pembayaran
Bill Pembayaran Bill Pembayaran
Cetak Bukti Pembayaran
Bukti Pembayaran Arsip
Tamu Front Office
10. Flowchart Check-Out
Front Office Manager
Tamu
Laporan Pendaftaran Tamu
Pembuatan Laporan Pendaftaran Tamu
Laporan Pendaftaran Tamu
Transaksi FasilitasTransaksi Fasilitas
Pembuatan Laporan Keuangan
Laporan Pendaftaran TamuLaporan Pendaftaran Tamu
11. Flowchart Pembuatan Laporan
B. Pemodelan Sistem Berbasis WEB (UML)
UML (Unified Modeling Language) adalah metode pemodelan (tools /
model) secara visual sebagai sarana untuk merancang dan atau membuat
software berorientasi objek dan memberikan standar penulisan sebuah
sistem untuk pengembangan sebuah software yang dapat menyampaikan
beberapa informasi untuk proses implementasi pengembangan software.
Karena berorientasi objek makasemua elemen dan diagram
berbasiskan pada paradigma object oriented, oleh karena itu UML dapat
secara langsung dihubungkan ke berbagai bahasa pemograman atau
bahkan dihubungkan secara langsung ke dalam sebuah object – oriented
database. Berikut adalah studi kasus dari Pemodelan Sistem Berbasis
WEB (UML) pada Sistem Parkir :
1. Activity Diagram
Activity diagrams menggambarkan berbagai alir aktivitas dalam
sistem yang sedang dirancang, bagaimana masing-masing alir
berawal, decision yang mungkin terjadi, dan bagaimana mereka
berakhir. Activity diagram juga dapat menggambarkan proses paralel
yang mungkin terjadi pada beberapa eksekusi.
Activity diagram merupakan state diagram khusus, di mana
sebagian besar state adalah action dan sebagian besar transisi di-
trigger oleh selesainya state sebelumnya (internal processing). Oleh
karena itu activity diagram tidak menggambarkan behaviour internal
sebuah sistem (dan interaksi antar subsistem) secara eksak, tetapi
lebih menggambarkan proses-proses dan jalur-jalur aktivitas dari level
atas secara umum.
Sebuah aktivitas dapat direalisasikan oleh satu use case atau
lebih. Aktivitas menggambarkan proses yang berjalan, sementara use
case menggambarkan bagaimana aktor menggunakan sistem untuk
melakukan aktivitas.
Sama seperti state, standar UML menggunakan segiempat
dengan sudut membulat untuk menggambarkan aktivitas. Decision
digunakan untuk menggambarkan behaviour pada kondisi tertentu.
Untuk mengilustrasikan proses-proses paralel (fork dan join) digunakan
titik sinkronisasi yang dapat berupa titik, garis horizontal atau vertikal.
Activity diagram dapat dibagi menjadi beberapa object swimlane untuk
menggambarkan objek mana yang bertanggung jawab untuk aktivitas
tertentu. Berikut adalah contoh dari activity diagram pada system
informasi parkir:
(Gambar Diagram activity masuk)
(Gambar diargram activity keluar)
2. Class Diagram
Class adalah sebuah spesifikasi yang jika diinstansiasi akan
menghasilkan sebuah objek dan merupakan inti dari pengembangan
dan desain berorientasi objek. Class menggambarkan keadaan
(atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk
memanipulasi keadaan tersebut (metoda/fungsi).
Class diagram menggambarkan struktur dan deskripsi class,
package dan objek beserta hubungan satu sama lain seperti
containment, pewarisan, asosiasi, dan lain-lain.Class memiliki tiga area
pokok :
1. Nama (dan stereotype)
2. Atribut
3. Metoda
Atribut dan metoda dapat memiliki salah satu sifat berikut :
1. Private, tidak dapat dipanggil dari luar class yang bersangkutan
2. Protected, hanya dapat dipanggil oleh class yang bersangkutan dan
anak-anak yang mewarisinya
3. Public, dapat dipanggil oleh siapa saja
Class dapat merupakan implementasi dari sebuah interface,
yaitu class abstrak yang hanya memiliki metoda. Interface tidak dapat
langsung diinstansiasikan, tetapi harus diimplementasikan dahulu
menjadi sebuah class. Dengan demikian interface mendukung resolusi
metoda pada saat run-time.
(Gambar class diagram)
3. Collaboration Diagram
Collaboration diagram juga menggambarkan interaksi antar
objek seperti sequence diagram, tetapi lebih menekankan pada peran
masing-masing objek dan bukan pada waktu penyampaian message.
Setiap message memiliki sequence number, di mana message dari
level tertinggi memiliki nomor 1. Messages dari level yang sama
memiliki prefiks yang sama
(Gambar collaboration diagram masuk)
(Gambar collaboration diagram keluar)
4. Component Diagram
Component diagram menggambarkan struktur dan hubungan
antar komponen piranti lunak, termasuk ketergantungan dependency)
di antaranya: Komponen piranti lunak adalah modul berisi code, baik
berisi source code maupun binary code, baik library maupun
executable, baik yang muncul pada compile time, link time, maupun
run time. Umumnya komponen terbentuk dari beberapa class dan/atau
package, tapi dapat juga dari komponen-komponen yang lebih kecil.
Komponen dapat juga berupa interface, yaitu kumpulan layanan yang
disediakan sebuah komponen untuk komponen lain.
(gambar component diagram)
5. Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di
dalam dan di sekitar sistem (termasuk pengguna, display, dan
sebagainya) berupa message yang digambarkan terhadap waktu.
Sequence diagram terdiri atar dimensi vertical (waktu) dan dimensi
horizontal (objek-objek yang terkait).
Sequence diagram biasa digunakan untuk menggambarkan
skenario atau rangkaian langkah-langkah yang dilakukan sebagai
respons dari sebuah event untuk menghasilkan output tertentu.
Diawali dari apa yang men-trigger aktivitas tersebut, proses dan
perubahan apa saja yang terjadi secara internal dan output apa yang
dihasilkan.
Masing-masing objek, termasuk aktor, memiliki lifeline vertikal.
Message digambarkan sebagai garis berpanah dari satu objek ke objek
lainnya. Pada fase desain berikutnya, message akan dipetakan
menjadi operasi/metoda dari class. Activation bar menunjukkan
lamanya eksekusi sebuah proses, biasanya diawali dengan
diterimanya sebuah message.
Untuk objek-objek yang memiliki sifat khusus, standar UML
mendefinisikan icon khusus untuk objek boundary, controller dan
persistent entity. Berikut adalah gambar sequence diagram.
(gambar sequence diagram masuk)
(gambar sequence diagram keluar)
6. Deployment Diagram
Deployment/physical diagram menggambarkan detail bagaimana
komponen di-deploy dalam infrastruktur sistem, di mana komponen
akan terletak (pada mesin, server atau piranti keras apa), bagaimana
kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-
hal lain yang bersifat fisikal
Sebuah node adalah server, workstation, atau piranti keras lain
yang digunakan untuk men-deploy komponen dalam lingkungan
sebenarnya. Hubungan antar node (misalnya TCP/IP) dan requirement
dapat juga didefinisikan dalam diagram ini.
(Gambar deployment diagram)
7. Statechart Diagram
Statechart diagram menggambarkan transisi dan perubahan
keadaan (dari satu state ke state lainnya) suatu objek pada sistem
sebagai akibat dari stimuli yang diterima. Pada umumnya statechart
diagram menggambarkan class tertentu (satu class dapat memiliki
lebih dari satu statechart diagram).
Dalam UML, state digambarkan berbentuk segiempat dengan
sudut membulat dan memiliki nama sesuai kondisinya saat itu. Transisi
antar state umumnya memiliki kondisi guard yang merupakan syarat
terjadinya transisi yang bersangkutan, dituliskan dalam kurung siku.
Action yang dilakukan sebagai akibat dari event tertentu dituliskan
dengan diawali garis miring. Titik awal dan akhir digambarkan
berbentuk lingkaran berwarna penuh dan berwarna setengah. Contoh
statechart diagram :
(gambar statechart diagram)
8. Use Case Diagram
UsE case diagram menggambarkan fungsionalitas yang
diharapkan dari sebuah sistem. Yang ditekankan adalah “apa” yang
diperbuat sistem, dan bukan “bagaimana”. Sebuah use case
merepresentasikan sebuah interaksi antara actor dengan sistem. Use
case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem,
meng-create sebuah daftar belanja, dan sebagainya.
Seorang/sebuah aktor adalah sebuah entitas manusia atau mesin
yang berinteraksi dengan sistem untuk melakukan pekerjaan-
pekerjaan tertentu. Use case diagram dapat sangat membantu bila
kita sedang menyusun requirement sebuah sistem,
mengkomunikasikan rancangan dengan klien, dan merancang test
case untuk semua feature yang ada pada sistem.
Sebuah use case dapat meng-include fungsionalitas use case lain
sebagai bagian dari proses dalam dirinya. Secara umum diasumsikan
bahwa use case yang di-include akan dipanggil setiap kali use case
yang meng-include dieksekusi secara normal. Sebuah use case dapat
di-include oleh lebih dari satu use case lain, sehingga duplikasi
fungsionalitas dapat dihindari dengan cara menarik keluar
fungsionalitas yang common.
Sebuah use case juga dapat meng-extend use case lain dengan
behaviour-nya sendiri. Sementara hubungan generalisasi antar use
case menunjukkan bahwa use case yang satu merupakan spesialisasi
dari yang lain
(gambar Use case diagram keluar)
(gambar use case diagram masuk)
BAB III
PENUTUP
A. Kesimpulan
Dari pembahasan diatas maka kami dapat menyimpulkan bahwa
dengan adanya pemodelan terstruktur dan pemodelan berbasis WEB
(UML) kita dapat lebih mudah merancang, membaca, memahami
sistem informasi dan memudahkan kita membuat sistem/
mengupgrade sistem baru yang lebih baik dan lebih efektif serta
efisien.
DAFTAR PUSTAKA
http://nakblogonline.com/uml-unified-modeling-language/
http://npaperbox.com/download/document/16
http://gangsir.com
http://wiki.com
http://haryantoyuli.blogspot.com/2010/07/state-transition-
diagram.html
http://aidarahman010692.blogspot.com/2011/12/pengertian-erd-dan-
dfd-dan-contoh_16.html
http://en.wikipedia.org/wiki/Structured_Analysis_and_Design_Technique
http://lytya-24.blogspot.com/2012/01/perbedaan-sistem-objek-
oriented-dan.html
http://en.wikipedia.org/wiki/Jackson_structured_programming
http://en.wikipedia.org/wiki/Warnier/Orr_diagram