Date post: | 23-Mar-2019 |
Category: |
Documents |
Upload: | hoangkhanh |
View: | 235 times |
Download: | 0 times |
DAFTAR ISI
BAB I DATA FLOW DIAGRAM (DFD)
Data Flow Diagram And Flow Chart Pemodelan
Perangkat Lunak
BAB II USE CASE DIAGRAM
Use Case Diagram
BAB I
DATA FLOW DIAGRAM (DFD)
Data Flow Diagram and Flow Chart Pemodelan
Perangkat Lunak
DFD Definition
Adalah suatu diagram yang menggunakan notasi-
notasi untuk menggambarkan arus dari data
sistem, yang penggunaannya sangat membantu
untuk memahami sistem secara logika, tersruktur
dan jelas.
Digunakan sebagai perangkat penting dalam
memodelkan sistem
Data Flow Diagram
Penggunaan DFD dipopulerkan oleh DeMarco –
Yordan dan Gane – Sarson dengan menggunakan
pendekatan Metoda Analisis Sistem Terstruktur
(SSADM).
DFD Symbol
External Entity
Entitas (kesatuan) diluar sistem yang akan
dimodelkan.
Memberikan input atau menerima output dari/ke
sistem.
Berupa orang, organisasi, sumber informasi lain
atau penerima akhir suatu laporan
Contoh :
External Entity :
• Entitas Yang Berada Diluar Sistem, Yang
Memberikan Data Kepada Sistem (Source) Atau
Mahasiswa Yayasan
Yang Menerima Informasi Dari Sistem (Sink),
Dapat Berupa Orang, Organisasi Dll.
• Tidak Termasuk Bagian Dari Sistem.
• Terminal Tidak Boleh Memiliki Nama Yang
Sama Kecuali Memang Objeknya Sama
(Digambarkan 2 X, Bila Demikian Perlu Diberi
Garis Miring.
Process (Proses)
Merupakan pekerjaan atau kegiatan yang
dilakukan orang atau komputer, dimana aliran
data masuk, ditransformasikan ke aliran data
keluar
Contoh :
Proses (Process)
Proses adalah kegiatan atau kerja yang dilakukan
oleh orang, mesin atau komputer dari input arus
data untuk menghasilkan output arus data
Proses
Suatu Proses Adalah Kegiatan Atau Kerja Yang
Dilakukan Oleh Orang, Mesin Atau Komputer Dari
Hasil Arus Data Yang Masuk Ke Dalam Proses Untuk
Dihasilkan Arus Data Yang Akan Keluar Dari Proses.
Menggambarkan Apa Yang Dilakukan Oleh Sistem.
Berfungsi Mentrans Formasikan Satu Atau Beberapa
Data Keluaran Sesuai Dengan Spesifikasi Yang
Diinginkan.
identifikasi
Nama Proses
Pemroses
Identi-
fikasi
2
Hitung
Gaji Personali
Setiap Proses Memiliki Satu Atau Beberapa Data
Masukan Serta Menghasilkan Satu Atau Beberapa Data
Keluaran
• Proses Sering Juga Disebut Sebagai Bubble.
• Nama Proses Terdiri Dari Kata Kerja Dan Kata
Benda Yang Mencerminkan Fungsi Proses
Tersebut, Misalnya : Hitung Gaji, Pendataan
Order, Cetak Laporan Penjulan.
• Jangan Mengugunakan Kata „Proses‟ Sebagai
Bagian Dari Nama Suatu Proses (Bubble).
Data Flow (Arus Data)
Menggambarkan aliran data dari satu proses ke
proses lain
Menggunakan anak panah
Contoh bentuk penggunaan :
Laporan tercetak yang dihasilkan sistem
Output pada layar komputer
Masukan untuk komputer
Komunikasi ucapan
Dsb…
Data Flow Concept – Cont.
Convergen Data Flow ( Arus data Mengumpul)
◦ Arus data yang mengumpul, yaitu Arus
data yang berbeda dari sumber yang
berbeda mengumpul ke tujuan yang sama
Data Store (Penyimpanan Data)
Dapat berupa suatu file atau suatu sistem
database dari suatu komputer, suatu
arsip/dokumen, suatu agenda/buku`
Data Store
• Tempat Menyimpan Data (Database= File/Table,
Arsip,buku Catatan).
• Proses Dapat Mengambil Data Dari Atau
Memberikan Data Ke Data Store.
• Nama Data Store Harus Mencerminkan Isi Dari
Data Store Tersebut.
• Bila Namanya Lebih Dari Satu Kata , Maka
Harus Diberi Kata Sambung.
Hal-Hal “di larang” dalam DFD
Mencegah
proses yang
mempunyai
masukan tetapi
tidak
mempunyai
keluaran yang
dikenal
dengan lubang
hitam (black-
hole)
Mencegah proses yang
mempunyai
keluaran tetapi
tidak punya masukan, misalnya penghasil
bilangan acak.
Hati-hati dengan aliran dan proses yang tidak
dinamakan karena dapat mengakibatkan elemen
data yang saling tidak berhubungan menjadi satu.
Hati-hati dengan penyimpanan yang punya status
hanya dapat dibaca atau hanya dapat ditulis dan
berkaitan dengan proses yang hanya memproses
masukan atau hanya memproses keluaran.
Langkah-langkah pembuatan DFD
Identifikasi semua kesatuan luar yang terlibat
dengan sistem
Identifikasi input dan output yang berhubungan
dengan kesatuan luar
Buatlah gambaran dari konteks diagram
Level DFD
DFD dapat diturunkan kedalam beberapa level
dimana level yang rendah harus bisa
mereprensentasikan proses tersebut dalam
spesifikasi proses yang lebih jelas
Diagram 0
Setelah pembuatan kontext akan dilanjutkan
dengan pembuatan :
◦ DFD level 0 : Penggambaran context
diagram yang lebih rinci (overview
diagram)
Hal Yang harus diperhatikan :
◦ Dapat memperlihatkan data store yang
digunakan
◦ Keseimbangan antara diagram kontex dan
diagram nol harus dipelihara
Diagram Rinci
DFD level 1: Tiap-tiap proses level 0 akan
digambarkan rinci
Hal Yang harus diperhatikan :
Keseimbangan data store yang digunakan
Keseimbangan aliran data antara diagram
nol dan diagram rinci
Contoh Penomoran Proses
Peraturan Penting DFD
Semua objek harus memiliki nama
Aliran data harus diawali dan diakhiri oleh proses
Semua aliran data harus memiliki tanda panah
Teknik Membuat DFD
1. Identifikasi Nama Setiap External Entity.
A. Entitas Yang Berada Diluar Sistem, Yang
Memberikan Data Kepada Sistem (Source) Tau
Yang Menerima Informasi Dari Sistem (Sink),
Dapat Berupa Orang, Organisasi Dll.
B. Tidak Termasuk Bagian Dari Sistem Artinya External
Entity Tidak Pernah Melakukan Proses Baca Atau Tulis
Didalam Tempat Penyimpanan Data (Data Store).
C. Nama Terminal (External Entity) Berupa Kata Benda.
Contoh : Pelanggan, Pemasok, Manajer, Gudang Dll.
Menggambarkan Sistem Yang Berjalan
Menggunakan DFD
Prosedur Sistem yang Sedang Berjalan
1. Konsumen atau pelanggan datang langsung atau
dapat memesan melalui via telepon ke Toko
Hegar untuk membeli bahan – bahan / Material
yang mereka butuhkan.
2. Setelah itu Pegawai Toko Hegar akan mengecek
persediaan / Stok Barang dengan kondisi :
Apakah barang yang di pesan ada / tidak dan
cukup / tidak ?. Apabila barang yang dipesan
tidak ada maka pegawai akan melakukan
penolakan atas barang yang dipesan tersebut.
3. Jika barang yang di pesan ada dan pelanggan /
Konsumen akan membayar pesanannya tersebut
secara tunai maka Petugas akan membuatkan
Nota Penjualan yang akan diberikan pada
pelanggan dan copy nota penjualan tersebut akan
diberikan kepada Pegawai Toko Hegar.
4. Namun jika mereka adalah pelanggan tetap yang
ingin membayar secara kredit / Tempo maka
petugas akan memberikan nota penjualan dan
nota piutang kepada pelanggan.
5. Dan copy nota piutang akan diberikan ke
pegawai yang kemudian akan digunakan untuk
menagih piutang kepada yang bersangkutan
berdasarkan tanggal akhir jatuh tempo piutang.
6. Jika pelanggan membeli bahan – bahan / material
melalui via telepon atau meminta bahan – bahan /
Material yang mereka di beli untuk diantarkan
ketempat mereka, maka petugas akan
memberikan surat jalan.
7. Apabila barang tersebut telah sampai maka
pelanggan / Konsumen akan memberikan copyan
surat jalan yang telah ditanda tangani kepada
sopir pengantar barang lalu kemudian sopir
tersebut akan memberikan copyan surat jalan tadi
kepada pegawai sebagai bukti bahwa barang
telah selesai diantarkan ketempatnya.
8. Jika ternyata Stok Barang tertentu habis maka
pegawai akan melakukan pembelian barang
kepada suplier – supliernya berdasarkan barang
yang telah habis.
9. Pegawai akan memberikan daftar pemesan
barang ke suplier lalu kemudian suplier akan
memberikan informasi apakah barang yang
dipesan ada / tidak. Jika ada maka barangnya
akan langsung diberikan kepada pegawai oleh
Toko Hegar yang disertai dengan nota dan faktur
pembelian.
10. Setiap harinya pegawai akan memberikan setiap
nota penjualan dan pembelian barang kepada
direktur Toko Hegar.
BAB II
USE CASE DIAGRAM
USE CASE DIAGRAM
• Menggambarkan fungsionalitas yang diharapkan
dari sebuah sistem. Yang ditekankan adalah “apa”
yang diperbuat sistem, dan bukan “bagaimana”.
• Menggambarkan kebutuhan system dari sudut
pandang user
• Mengfokuskan pada proses komputerisasi
(automated processes)
• Menggambarkan hubungan antara use case dan
actor
• Use case menggambarkan proses system
(kebutuhan system dari sudut pandang user)
• Secara umum use case adalah:
Pola perilaku system
Urutan transaksi yang berhubungan
yang dilakukan oleh satu actor
• Use case diagram terdiri dari
Use case
Actors
Relationship
System boundary boxes (optional)
Packages (optional)
USE CASE
• Use case dibuat berdasar keperluan actor,
merupakan “apa” yang dikerjakan system,
bukan “bagaimana” system mengerjakannya
• Use case diberi nama yang menyatakan apa
hal yang dicapai dari hasil interaksinya
dengan actor.
• Use case dinotasikan dengan gambar
(horizontal ellipse)
• Use case biasanya menggunakan kata kerja
• Nama use case boleh terdiri dari beberapa
kata dan tidak boleh ada 2 use case yang
memiliki nama yang sama
ACTOR
• Actor menggambarkan orang, system atau
external entitas / stakeholder yang
menyediakan atau menerima informasi dari
system
• Actor menggambarkan sebuah tugas/peran
dan bukannya posisi sebuah jabatan
• Actor memberi input atau menerima
informasi dari system
• Actor biasanya menggunakan Kata benda
• Tidak boleh ada komunikasi langsung antar
actor
• Indikasi <<system>> untuk sebuah actor
yang merupakan sebuah system
• Adanya actor bernama “Time” yang
mengindikasikan scheduled events (suatu
kejadian yang terjadi secara periodik/bulanan)
• Letakkan actor utama anda pada pojok kiri
atas dari diagram
Association
• Associations bukan menggambarkan aliran
data/informasi
• Associations digunakan untuk
menggambarkan bagaimana actor terlibat
dalam use case
• Ada 4 jenis relasi yang bisa timbul pada use
case diagram
1. Association antara actor dan
use case
2. Association antara use case
3. Generalization/Inheritance
antara use case
4. Generalization/Inheritance
antara actors
Association antara actor dan use case
• Ujung panah pada association antara actor dan
use case mengindikasikan siapa/apa yang
meminta interaksi dan bukannya
mengindikasikan aliran data
• Sebaiknya gunakan Garis tanpa panah untuk
association antara actor dan use case
• association antara actor dan use case yang
menggunakan panah terbuka untuk
mengindikasikan bila actor berinteraksi secara
pasif dengan system anda
• <<include>> termasuk didalam use case lain
(required) / (diharuskan)
– Pemanggilan use case oleh use case lain,
contohnya adalah pemanggilan sebuah
fungsi program
– Tanda panah terbuka harus terarah ke sub
use case
– Gambarkan association include secara
horizontal
Buka
Rekening
<<include>>catat
data
pribadi
Nasabah
• <<extend>> perluasan dari use case lain jika
kondisi atau syarat terpenuhi
– Kurangi penggunaan association Extend
ini, terlalu banyak pemakaian association
ini membuat diagram sulit dipahami.
– Tanda panah terbuka harus terarah ke
parent/base use case
Register for courses
<<include>>
– Gambarkan association extend secara
vertical
Buka
Rekening
<<extend>>
Buka
Deposito
Nasabah
Generalization/inheritance antara use case
• Generalization/inheritance digambarkan dengan
sebuah garis berpanah tertutup pada salah satu
ujungnya yang menunjukkan lebih umum
• Gambarkan generalization/inheritance antara use
case secara vertical dengan inheriting use case
dibawah base/parent use case
• Generalization/inheritance dipakai ketika ada
sebuah keadaan yang lain sendiri/perlakuan
khusus (single condition)
Buka
Rekening
Nasabah Buka
Deposito
• Gambarkan generalization/inheritance antara
actors secara vertical dengan inheriting actor
dibawah base/parent use case
Use case System boundary boxes
• Digambarkan dengan kotak disekitar use case,
untuk menggambarkan jangkauan system anda
(scope of of your system).
• Biasanya digunakan apabila memberikan
beberapa alternative system yang dapat dijadikan
pilihan
• System boundary boxes dalam penggunaannya
optional