PEMODELAN SISTEM

INFORMASI
I1B -P e m o d e la n Si st em In for m a si
P SI 5 - 1
State Machine Diagram (Statechart diagram in versi 1.x)
Untuk memodelkan behavior/methode (lifecycle) sebuah kelas atau object
Memperlihatkan urutan kejadian sesaat (state) yang dilalui sebuah object,
transisi dari sebuah state ke state lainnya

F a k u lt a s T e k n ol o g i I n f o r m a si - U n i v e r s i t a s B u d i Lu h u r
 Konsep Dasar Sistem Informasi
 Sistem Informasi
Suatu sistem di dalam suatu organisasi yang
mempertemukan kebutuhan pengolahan transaksi harian
yang mendukung fungsi operasi organisasi
 Konsep Dasar Sistem Informasi
 Sistem
› Seperangkat unsur-unsur yang terdiri dari manusia,
mesin atau alat dan prosedur serta konsep-konsep
yang dihimpun menjadi satu untuk maksud dan tujuan
bersama
 Informasi
› Data yang dioleh menjadi bentuk yang lebih berguna
dan berarti bagi yang menerimanya
 Pengembangan Sistem
 Menyusun sistem baru utk menggantikan sistem lama secara
keseluruhan atau memeperbaiki sistem yg telah ada.
SYSTEM DEVELOPMENT LIFE
CYCLE
(SDLC)
Identifikasi : sasaran,
jangka waktu,
dana,team
Mempelajari /mendefenisikan sistem
yg sedang berjalan

rinci/de
tail
Perencanaan:
Keuntungan dari merencanakan proyek SI:
· Menentukan lingkup dari proyek;
· Mengenali berbagai area permasalahan potensial;
· Mengatur urutan tugas;
· Memberikan dasar untuk pengendalian.
Analisis:
1) Mengumumkan Penelitian Sistem:
untuk mengurangi kekuatiran akan adanya aplikasi komputer
baru, kiranya perlu dikomunikasikan dengan cara
(a)alasan perusahaan melaksanakan proyek;
(b)bagaimana sistem baru akan menguntungkan perusahaan
dan pegawai;

2) Mengorganisasikan tim proyek:

sebaiknya pemimpin proyek adalah spesialis informasi,
jangan pemakai;
3) Mendefinisikan kebutuhan pemakai:
pengumpulan informasi kebutuhan pemakai dapat dilakukan
dengan: wawancara perorangan, pengamatan, pencarian
catatan dan survei. Wawancara lebih disukai, karena:
(1) adanya komunikasi dua arah dan pengamatan terhadap
bahasa tubuh;
(2) meningkatkan antusiasme pada proyek baik dari pihak
spesialis, maupun pemakai;
(3) dapat menjalin kepercayaan antara pemakai dan spesialis
informasi;
(4) memberi kesempatan bagi peserta proyek kalau ada
perbedaan pandangan.
Dokumentasinya dapat berupa flowchart, diagram arus data
(data flow diagram), dan grafik serta penjelasan naratif dari
proses dan data.
Semua dokumentasi ini yang menjelaskan sistem ini disebut
kamus proyek.
4) Mendefinisikan kriteria kinerja sistem:
setelah kebutuhan informasi didefinisikan, langkah selanjutnya
adalah menspesifikasikan secara tepat kriteria kinerja sistem.
Contoh, manajer pemasaran menetapkan kriteria laporan biaya
bulanan sbb:
(1) laporan disiapkan dalam kertas dan tampilan; (2) laporan
disediakan tidak lebih dari 3 hari setelah
akhir bulan;
(3) laporan harus membandingkan pendapatan dan biaya aktual
dengan anggaran.
5) Menyiapkan usulan rancangan:
analis sistem memberikan kesempatan bagi manajer untuk
membuat keputusan teruskan/ hentikan untuk kedua kalinya.
Manajer harus menyetujui tahap rancangan dan dukungan bagi
keputusan itu termasuk usulan rancangan.
6) Menyetujui atau menolak rancangan proyek:
manajer dan komite pengarah SIM mengevaluasi usulan
rancangan dan menentukan apakah disetujui atau tidak.
Perancangan:
Langkah-langkahnya adalah sebagai berikut:
1) Menyiapkan rancangan sistem yang terinci:
analis bekerja sama dengan pemakai dan mendokumentasikan rancangan sistem
baru dengan alat-alat yang telah dijelaskan dalam modul teknis.
Penggambaran dilakukan dari yang besar dan secara bertahap secara rinci dengan
pendekatan top-down dan ini biasanya dilakukan untuk rancangan terstruktur
(structured design).
2) Mengidentifikasikan berbagai alternatif konfigurasi sistem:
Analis harus mengidentifikasikan konfigurasi (bukan merek atau model) peralatan
komputer yang akan memberikan hasil terbaik bagi sistem untuk menyelesaikan
pemrosesan.
3) Mengevaluasi berbagai alternatif konfigurasi sistem:
analis bekerja bersama manajer mengevaluasi berbagai alternatif dan dipilih
yangpaling memungkinkan subsistem memenuhi kriteria kinerja, dengan kendala-
kendala yang ada.
4) Memilih konfigurasi yang terbaik:
analis mengevaluasi semua konfigurasi subsistem dengan menyesuaikan kombinasi
peralatan sehingga semua subsistem menjadi satu konfigurasi tunggal. Setelah
dianalisis kemudian direkomendasikan kepada manajer untuk disetujui. Persetujuan
dilakukan oleh Komite pengarah SIM.
5) Menyetujui usulan penerapan:
analisis menyiapkan usulan penerapan yang mengikhtisarkan tugas-tugas penerapan
yang harus dilakukan, keuntungan yang diharapkan dan biayanya.
6) Menyetujui atau menolak penerapan sistem:
jika keuntungan dari sistem melebihi biayanya, penerapan akan disetujui.
 Metodologi Pengembangan
Sistem
Yaitu :
metode-metode, prosedur-prosedur, konsep-
konsep pekerjaan, aturan-aturan yang akan
digunakan sebagai pedoman bagaimana dan
apa yang harus dikerjakan selama
pengembangan ini.
Metodologi Pengembangan Sistem
 Metode dalam penerapan tahapan pengembangan SI 
Daur Hidup Pengembangan Sistem (System Development
Life Cycle (SDLC))
Waterfall (Model air terjun)
 Defenis
i
kebutu
Perancangan
han
sistem

Pemasangan
sistem

Pengoperasian
sistem

Sistem menjadi
usang
 Pemodelan
 Model
› Suatu penyederhanaan dari yang nyata
› Menyediakan cetak biru (blue print) dari suatu sistem
› Suatu perwakilan atau abstraksi dari suatu objek atau
situasi aktual
 Pemodelan
› Rangkaian aktivitas pembuatan model
 Banyak bentuk model yang digunakan dalam
perancangan sistem, diantaranya :
› model narasi
› Model prototype
› Model grafis
› Dll
 Perangkat yang digunakan untuk pemodelan suatu
sistem :
› Aliran Sistem Informasi (ASI)
› Contex Diagram
› Data flow diagram
› Kamus data
› UML (Unified Modeling Language)
 Berbagai model penggambaran sistem
a. Model sistem yang logis (logical system model)
Melukiskan suatu sistem atau apa yang harus dikerjakan oleh
suatu sistem, dan bukan bagaiman suatu sistem harus
diimplementasikan
Menggambarkan kebutuhan utama sisten (essential system
model)
b. Model rinci untuk proses, misalnya DFD level rinci
c. Model untuk data, mis ERD
d. Model utk menggambarkan interface, mis Context Diagram
e. Model utk menggambarkan objek, mis UML
f. dll
 ALIRAN SISTEM INFORMASI
(ASI)
 Disebut juga document flowchart atau form flowchart atau
Bagan Alir Dokumen (BAD)
 Merupakan salah satu alat bantu perancangan sistem untuk
menunjukkan bagan alir sistem dari sebuah organisasi
 Menunjukkan urut-urutan dokumen dari satu bagian ke
bagian lainnya, proses-proses yang dilakukan sehingga
menghasilkan serangkaian informasi.
 Yang menjadi tolok ukur prosedur-prosedur apa yang
harus dibenahi dalam sebuah organisasi, apakah perlu
dipotong, ditambah, di komputerisasikan dan lain
sebagainya.
Simbol-simbol ASI
Sistem informasi Penjualan:
 1. Distributor yang menyerahkan nota permintaan barang pada bagian
marketing.
 2. Bagian merketing kemudian mencek nota yang diterima tersebut dan
kemudian diserahkan pada bagian logistik.
 3. Bagian logistik melakukan pengecekan persedian dari barang yang diminta
dan langsung membuat faktur penjualan dari barang-barang yang dipesan.
faktur dibuat rangkap tiga
 4. Rangkap satu dan dua diserahkan ke bagian marketting.
 5. Rangkap ketiga disimpan sebagai arsip.
 6. Marketting menyerahkan Faktur kepada distributor beserta barang yang
dipesan sebagai bukti transaksi penjualan.
 7. Faktur yang tinggal pada bagian marketting diolah menjadi daftar
penjualan.
 8. Bagian marketing kemudian membuat laporan penjualan berdasarkan
daftar penjualan.
 9. Laporan dibuat rangkap dua, rangkap pertama diserahkan pada direktur dan
yang kedua disimpan sebagai arsip.
 TUGAS .....
Sistem Pemesanan Barang pada PT. Kelana Bahari
 Bagian gudang menyerahkan orderan kepada supervisor keuangan
 Oleh supervisor keuangan permintaan orderan diproses dan membuatkan daftar
orderan untuk dikirim ke kantor pusat.
 Daftar orderan yang diterima oleh kantor pusat digunakan untuk proses
pengadaan, kemudian mengirimkan daftar pengiriman orderan pada supervisor
keuangan.
 Oleh supervisor keuangan daftar pengiriman orderan diberikan ke bagian
gudang.
 Bagian gudang membuat laporan penerimaan barang sebanyak 3 rangkap
berdasarkan daftar pengiriman order, kemudian laporan tadi diberikan ke
supervisor keuangan untuk di acc.
 Laporan penerimaan barang yang di acc oleh supervisor keuangan satu rangkap
diarsip, satu rangkap diberikan ke manager operasi dan satu rangkap lagi
diberikan ke bagian gudang.
 
 TUGAS .....
 Jika terjadi permintaan barang dari loket, bagian gudang akan
melakukan pengecekan stock dan membuat daftar pengeluaran
barang.
 Berdasarkan laporan penerimaan barang yang di acc dan daftar
pengeluaran barang, bagian gudang membuat laporan pengeluaran
dan laporan persediaan sebanyak 3 rangkap, kemudian diberikan ke
manager operasi untuk di acc.
 Manager operasi melakukan acc laporan
 Laporan yang telah di acc satu rangkap diarsipkan oleh manager
operasi, dua rangkap diberikan ke bagian gudang. Oleh bagian
gudang laporan tadi satu rangkap diarsip dan satu rangkap lagi
diberikan ke supervisor keuangan.
 
 CONTEXT DIAGRAM
 Merupakan kejadian tersendiri dari suatu
Diagram Alir Data (DAD/DFD)
 Satu lingkaran merepresentasikan seluruh sistem
 Harus berupa suatu pandangan, yang mencakup
masukan-masukan dasar, sistem-sistem dan
keluaran
 Tingkatan tertinggi dalam DFD
 Hanya memuat satu proses, menunjukkan sistem
secara keseluruhan
 Proses tersebut diberi nomor 0 (nol)
 Semua entitas eksternal berikut aliran data utama
menuju dan dari sistem
 Tidak memuat penyimpanan data
 CD menggarisbawahi sejumlah karakteristik dari
suatu sistem :
› Kelompok pemakai
 Organisasi atau sistem lain dimana sistem kita
melakukan komunikasi. Disebut juga TERMINATOR
› Data dimana sistem menerima dari lingkungan dan
harus diproses dgn cara tertentu
› Data yang dihasilkan sistem akan diberikan ke dunia
luar/ext entity
› Penyimpanan data yang digunakan bersama antara
sistem dengan terminator, dibuat oleh sistem dan
digunakan oleh terminator atau sebaliknya, dibuat
terminator dan digunakan oleh sistem
› Batasan antara sistem dengan lingkungannya
Contoh Context Diagram
Sistem Pemesanan Makanan
Context Diagram memiliki aturan :
a. Jika terdapat banyak terminator yang mempunyai banyak
masukan dan keluaran diperbolehkan untuk digambarkan
lebih dari satu kali, ditandai secara khusus untuk
menjelaskan bahwa terminator yang dimaksud adalah
identik. Berupa tanda asterik (*) atau pagar (#).
b. Jika terminator mewakili individu sebaiknya diwakili
oleh peran yang dimainkan personil tersebut. Alasan
pertama adalah personil yang berfungsi untuk melakukan
itu dapat berganti sedang Context Diagram harus tetap
akurat walaupun personil berganti. Alasan kedua adalah
seorang personil dapat memainkan lebih dari satu peran.
c. Karena fokus utama adalah mengembangkan model,
maka penting untuk membedakan 5`sesuatu yang
harus digambarkan lebih dari sumber data itu sendiri.
Sedangkan sistem baru dengan konsep
pengembangan teknologinya membuat pelaku
menjadi sesuatu yang tidak perlu digambarkan
Contoh Context Diagram dengan
duplikasi terminator
 Bentuk dari eksternal entity diantaranya adalah sebagai
berikut:
• Suatu kantor, departemen atau divisi dalam perusahaan
tetapi di luar sistem yang sedang dikembangkan.
• Orang/sekelompok orang di organisasi tetapi di luar sistem
yang sedang dikembangkan
• Suatu organisasi atau orang yang berada di luar organisasi
seperti misalnya langganan, pemasok, dll.
• Sistem informasi yang lain di luar sistem yang sedang
dikembangkan
• Sumber asli dari suatu transaksi
• Penerima akhir dari suatu laporan yang dihasilkan oleh
sistem
Data Flow Diagram (DFD)
 Data Flow Diagram (DFD)
 Empat simbol dasar yang digunakan untuk memetakan gerakan diagram
aliran data adalah:
 a. External Entity (Entitas)/terminator
 Dengan simbol sebagai berikut:

 Kotak ini digunakan untuk menggambarkan suatu entitas eksternal (bagian

lain, sebuah perusahaan, seseorang atau sebuah mesin) yang dapat mengirim
data atau menerima data dari sistem.
 Disebut juga sumber atau tujuan data, dan dianggap eksternal terhadap
sistem yang sedang digambarkan.
 Setiap entitas diberi label dengan sebuah nama yang sesuai.
 Meskipun berinteraksi dengan sistem, namun dianggap di luar batas-batas
sistem.
 Entitas-entitas tersebut harus diberi nama dengan suatu kata benda bisa
digunakan lebih dari sekali utk entitas yang sama
b. Data Flow/Arus data
 Simbol yang digunakan adalah tanda panah
berikut .

 Menunjukkan perpindahan data dari satu titik ke

titik yang lain, dengan kepala tanda panah
mengarah ke tujuan data.
 Harus digambarkan dalam kata benda.
 c. Process/Proses
 Proses-proses selalu menunjukkan suatu
perubahan data
 Jadi, aliran data yang meninggalkan suatu proses
selalu diberi label yang berbeda dari aliran data
yang masuk.
 Sebuah nama yang jelas memudahkan untuk
memahami proses apa yang sedang dilkukan.
Pemberian nama pada proses:
1. Menetapkan nama sistem secara keseluruhan saat menamai
proses pada level yang lebih tinggi. Contoh: sistem kontrol
inventaris.
2. Menamai suatu subsistem utama, menggunakna nama-nama
seperti : Sistem pelaporan inventaris atau Sistem pelayanan
konsumen internet.
3. Menggunakan format kata kerja – kata sifat – kata benda
untuk proses-proses yang mendetail.

Kata kerja yang menggambarkan jenis kegiatan yang seperti ini,

Misalnya menghitung, memverifikasi, menyiapkan, mencetak atau menambahkan.
 d. Data Store (Penyimpanan Data)
 Data store dilambangkan dengan bujur sangkar dengan ujung terbuka
 Menunjukkan penyimpanan data.
 Penyimpanan data menandakan penyimpanan manual, seperti lemari
file/sebuah file/basisdata terkomputerisasi. Diberi nama dengan
sebuah kata benda.
 Penyimpanan data sementara seperti kertas catatan/sebuah file
komputer sementara tidak dimasukkan ke dalam diagram aliran data.
Bentuk dari penyimpanan data diantaranya adalah sebagai berikut:
• Suatu file atau database di sistem komputer
• Suatu arsip atau catatan manual
• Suatu kotak tempat data di meja seseorang
• Suatu tabel acuan manual
• Suatu agenda atau buku
 Dalam penggambaran penyimpanan data perlu diperhatikan
beberapa hal, antara lain:
a. Hanya proses saja yang berhubungan dengan simpanan
data, karena yang mengggunakan/ merubah data di simpanan
data adalah suatu proses.
b. Arus data yang menuju ke simpanan data dari suatu
proses menunjukkan proses update terhadap data
yang tersimpan di simpanan data.
Update dapat berupa proses:
• Menambah/menyimpankan record baru atau dokumen baru ke
dalam simpanan data.
• Menghapus record atau mengambil dokumen dari simpanan data
• Merubah nilai data di suatu record atau di suatu dokumen yang
ada di simpanan data
c. Arus data yang berasal dari simpanan data ke
suatu proses menunjukkan bahwa proses tersebut
menggunakan data yang ada di simpanan data.
d. Untuk suatu proses yang melakukan kedua-
duanya yaitu menggunakan dan update simpanan
data dapat dipilih salah satu penggambaran.
•
 Menggambarkan sebuah garis dengan panah mengarah kedua
arah yang berlawanan dari simpanan data sebagai berikut:

Menggunakan arus data yang terpisah sebagai berikut:

Untuk menghindari garis arus data yang saling berpotongan sehingga

membuat gambar di DFD menjadi ruwet, maka simpanan
data/kesatuan luar dapat digambar lebih dari sebuah.
PENGGAMBARAN DFD
Tidak ada aturan baku untuk menggambarkan DFD, tapi dari berbagai referensi yg ada,
secara garis besar:
1. Buat diagram context
 Diagram ini adalah diagram level tertinggi dari DFD yg menggambarkan hubungan sistem
dengan lingkungan luarnya. Cara :
- Tentukan nama sistemnya.
- Tentukan batasan sistemnya.
- Tentukan terminator apa saja yg ada dalam sistem.
- Tentukan apa yg diterima/diberikan terminator dari/pada sistem.
- Gambarkan diagram context.
2. Buat diagram level Satu
 Diagram ini adalah dekomposisi dari diagram Context. Cara :

- Tentukan proses utama yg ada pada sistem.

 Tentukan apa yg diberikan/diterima masing-masing proses pada/dari sistem sambil
memperhatikan konsep keseimbangan (alur data yang keluar/masuk dari suatu level harus
sama dgn alur data yang masuk/keluar pada level berikutnya)
 Apabila diperlukan, munculkan data store (master) sebagai sumber maupun tujuan alur
data.
 Gambarkan diagram level satu.

- Hindari perpotongan arus data

- Beri nomor pada proses utama (nomor tidak menunjukkan urutan proses).
3. Buat diagram level Dua
 Diagram ini merupakan dekomposisi dari diagram level satu. Cara :
 Tentukan proses yg lebih kecil (sub-proses) dari proses utama yg ada di
level satu.
 Tentukan apa yg diberikan/diterima masing-masing sub-proses pada/dari
sistem dan perhatikan konsep keseimbangan.
 Apabila diperlukan, munculkan data store (transaksi) sbg sumber
maupun tujuan alur data.
- Gambarkan DFD level Dua
- Hindari perpotongan arus data.
 Beri nomor pada masing-masing sub-proses yang menunjukkan
dekomposisi dari proses sebelumnya. Contoh : 1.1, 1.2, 2.1
 4. DFD level tiga, empat..
 Diagram ini merupakan dekomposisi dari level sebelumnya.
 Proses dekomposisi dilakukan sampai dg proses siap dituangkan ke dalam
program.
 Aturan yg digunakan sama dgn level dua.

KESIMPULAN :
 Entity Relationship Diagram
 ERD adalah model konseptual yang mendeskripsikan
hubungan antara penyimpanan (dalam DFD).
 ERD digunakan untuk memodelkan struktur data dan
hubungan antar data.
 Dengan ERD, model dapat diuji dengan mengabaikan
proses yang dilakukan.
 ERD pertama kali dideskripsikan oleh Peter Chen yang
dibuat sebagai bagian dari perangkat lunak CASE.
 Notasi yang digunakan dalam ERD dapat dilihat pada
Tabel di bawah ini :
Langkah-langkah teknis yang dapat dilakukan untuk
mendapatkan ERD awal adalah :
1. Mengidentifikasi dan menetapkan seluruh himpunan
entitas yang akan terlibat.
2. Menetukan atribut-atribut key (kunci) dari masing-
masing himpunan entitas.
3. Mengidentifikasi dan menetapkan seluruh himpunan
relasi diantara himpunan entitas-himpunan entitas yang
ada beserta foreign-keynya (kunci asing/ kunci tamu).
4. Menentukan derajad /kardinalitas relasi untuk setiap
himpunan relasi.
5. Melengkapi himpunan entitas dan himpunan relasi
dengan atribut dekriptif (atribut yang bukan kunci)
 Kardinalitas Relasi
 Dalam ERD hubungan (relasi) dapat terdiri dari sejumlah entitas yang disebut
dengan derajad relasi.
 Derajad relasi maksimum disebut dengan kardinalitas sedangkan derajad minimum
disebut dengan modalitas.
 Kardinalitas relasi menunjukkan jumlah maksimum entitas yang dapat berelasi
dengan entitas pada himpunan entitas lain.
 Kardinalitas relasi yang terjadi diantara dua himpunan entitas (misalnya A dan B)
dapat berupa :
1. Satu ke satu (one to one/ 1-1)
Setiap entitas pada himpunan entitas A dapat berelasi dengan paling banyak satu
entitas pada himpunan entitas B, demikian juga sebaliknya.
2. Satu ke banyak (one to many/ 1- N)
Setiap entitas pada himpunan entitas A dapat berelasi dengan banyak entitas pada
himpunan entitas B, tetapi tidak sebaliknya.
3. Banyak ke banyak (many to many/ N –N)
Setiap entitas pada himpunan entitas A dapat berelasi dengan banyak entitas pada
himpunan entitas B, demikian juga sebaliknya.
 KAMUS DATA
 Model berikutnya yang akan dibahas adalah data
dictionary/DD (Kamus Data/KD).
 KD tidak menggunakan notasi grafis sebagaimana halnya
DAD, tetapi porsinya dalam memodelkan sistem tidak perlu
diragukan lagi (sebuah model tidak lengkap tanpa KD).
 KD berfungsi membantu pelaku sistem untuk mengerti
aplikasi secara detil
 KD mereorganisasi semua elemen data yang digunakan dalam
sistem dengan presisi yang sedemikan rupa sehingga pemakai
dan penganalisas sistem memiliki dasar pengertian yang sama
tentang masukan, keluaran, penyimpanan dan proses.
 Kamus Data adalah katalog fakta tentang data dan
kebutuhan-kebutuhan informasi dari suatu sistem
informasi.
 Kamus data selain digunakan untuk dokumentasi dan
mengurangi redudansi, juga dapat digunakan untuk:
1. Memvalidasi diagram aliran data dalam hal
kelengkapan dan keakuratan
2. Menyediakan suatu titik awal untuk mengembangkan
layar dan laporan-laporan
3. Menentukan muatan data yang disimpan dalam file-
file
4. Mengembangkan logika untuk proses-proses diagram
aliran data
 Kamus data dibuat berdasarkan arus data yang ada di DAD
 KD mendefinisikan elemen data dengan fungsi sebagai berikut:
Menjelaskan arti aliran data dan penyimpanan data

dalam DFD
Mendeskripsikan komposisi paket data yang bergerak

melalui aliran (misalnya alamat diuraikan menjadi kota,

negara dan kode pos)
- Mendeskripsikan komposisi penyimpanan data
Menspesifikasikan nilai dan satuan yang relevan bagi

penyimpanan dan aliran

Mendeskripsikan hubungan detil antar penyimpanan (yang
akan menjadi titik perhatian dalam entity-relationship diagram)
 KD mencerminkan keterangan yang jelas tentang data yang akan
dicatat.
 Untuk maksud keperluan ini, maka kamus data harus memuat hal-
hal berikut:
1. Nama arus data, karena kamus data dibuat berdasarkan arus
data yang mengalir di DAD, maka nama dari arus data juga
harus dicatat di KD.
2. Alias, alias atau nama lain dari data dapat dituliskan bila
nama lain ini ada. Alias perlu ditulis karena data yang sama
mempunyai nama yang berbeda untuk orang atau departemen satu
dengan yang lainnya. Misalnya bagian pembuat faktur dan
langganan menyebut bukti penjualan sebagai faktur, sedangkan
bagian gudang menyebutnya sebagai tembusan permintaan
persediaan.
 Baik faktur dan tembusan permintaan persediaan ini elemen yang
berbeda.
3. Bentuk data, telah diketahui bahwa arus data dapat
mengalir:
• Dari kesatuan luar ke suatu proses, data yang mengalir ini
biasanya tercatat di suatu dokumen atau formulir.
• Hasil dari suatu proses ke kesatuan luar, data yang
mengalir ini biasanya terdapat di media laporan atau
query tampilan layar atau dokumen hasil cetakan
komputer;
• Hasil suatu proses ke proses yang lain, data yang
mengalir ini biasanya dalam bentuk variabel atau
parameter yang dibutuhkan oleh proses penerimanya;
• Hasil suatu proses yang direkamkan ke simpanan data,
data yang mengalir ini biasanya berbentuk suatu variabel.
• Dari simpanan data dibaca oleh suatu proses, data yang
mengalir ini biasanya berupa suatu field (item data).
 Dengan demikian bentuk dari data yang mengalir
dapat berupa:
dokumen dasar atau formulir, dokumen hasil
cetakan komputer, laporan tercetak, tampilan di
layar monitor, variabel, parameter, field.
4. Arus data, arus data menunjukkan dari mana
data mengalir dan ke mana data akan menuju.
Keterangan ini perlu dicatat di KD agar mudah
mencari arus data di DAD.
5. Penjelasan, Untuk lebih memperjelas lagi tentang
makna dari arus data yang dicatat di KD, maka
bagian penjelasan dapat diisi dengan keterangan-
keterangan tentang arus data tersebut. Misalnya
nama dari arus data adalah Tembusan Permintaan
Persediaan, maka dapat lebih dijelaskan sebagai
tembusan dari faktur penjualan untuk meminta
barang dari gudang.
6. . Periode,
periode ini menunjukkan kapan terjadinya
arus data ini.
Periode perlu dicatat di KD karena dapat
digunakan untuk mengidentifikasikan kapan
input data harus dimasukkan ke sistem, kapan
proses dari program harus dilakukan dan kapan
laporan-laporan harus dihasilkan.
7.. Volume,
volume yang perlu dicatat di KD adalah tentang
volume rata-rata dan volume puncak dari arus data.
Volume rata-rata menunjukkan banyaknya rata-rata arus
data yang mengalir dalam satu periode tertentu dan volume
puncak menunjukkan volume yang terbanyak.
V olume ini digunakan untuk mengidentifikasikan besarnya
simpanan luar yang akan digunakan, kapasitas dan jumlah
dari alat input, alat pemroses dan alat output.
8. . Struktur data, struktur data menunjukkan arus data
yang dicatat di KD terdiri dari item item data apa saja.
 Contoh-contoh dari pemakaian simbol-simbol di atas, adalah:
Contoh 1:
Tembusan Permintan Persediaan = Kode Langganan +
Nama Langganan +
Tanggal Penjualan +
Nomor Faktur +
1{ Informasi Barang }5 +
Total Penjualan +
( Potongan Penjualan) +
Pajak Penjualan +
Total Dibayar +
Jenis Penjualan
Informasi Barang = Kode Barang +
Nama Barang +
Unit Jual +
Harga Satuan +
Total Harga
Jenis Penjualan = [ Cash | Credit ]
Contoh 2 :
Struktur Data:
Record Pegawai = Nomor Pegawai +
Informasi Pribadi +
Informasi Gaji +
Informasi Pembayaran Saat Ini +
Informasi Gaji Tahunan Sampai Hari Ini
Record File Waktu = Nomor Pegawai +
Nama Pegawai +
Jam Kerja
Pembayaran Cek Gaji = Nomor Pegawai +
Nama Pegawai +
Alamat +
Jumlah Pembayaran Saat Ini +
Jumlah Gaji Tahunan Sampai Saat Ini
Informasi Gaji = Perhitungan Pembayaran +
Jumlah Tanggungan
Jumlah Pembayaran Saat Ini = Gaji Kotor +
Potongan Pajak Pemerintah +
Potongan Pajak Negara Bagian +
Potongan Pajak Jaminan Sosial +
Gaji Bersih
Untuk mengecek kebenaran (kelengkapan, konsistensi dan
kontradiksi) dari kamus data, maka dapat digunakan testing
dengan sejumlah pertanyaan sebagai berikut:
• Apakah semua aliran dalam DFD sudah didefinisikan dalam
kamus data?
• Apakah semua komponen elemen data sudah didefinisikan?
• Adakah elemen data yang didefinisikan lebih dari satu kali?
• Apakah semua notasi yang digunakan pada kamus data
sudah dikoreksi?
• Adakah elemen data dalam kamus data tidak menjelaskan
sesuatu dalam data flow
diagram, entity relation atau state transition diagram?
UML

Unified Modeling
Language
Sejarah UML (Unified Modeling Language)
 Pada Oktober 1994, Dr. James Rumbaugh bergabung dengan Perusahaan Rational
sotware, dimana Grady Booch sudah bekerja disana sebelumnya. Grady Booch
mengembangkan Object Oriented Design (OOD) dan Dr. James Rumbaugh
mengembangkan Object Modeling Technique (OMT). Duet Mereka pada Oktober
1995 menghasilkan Unified Method versi 0.8.
 Musim gugur 1995 Dr. Ivar Jacobson ikut pula bergabung dengan duet Rumbaugh-
Booch, dengan memperkenalkan tool use case. Trio tersebut pada bulan Juni 1996
menghasilkan Unified Modeling Language (UML) versi 0.9. Sebelumnya Dr. Ivar
Jacobson mengembangkan Object Oriented Software Engineering (OOSE)
 Trio ini mengembangkan Ratinal Unified Process (RUP)
 Banyak perusahaan software merasakan bagaimana pentingnya UML dalam
tujuan strategis mereka, sehingga beberapa perusahaan membentuk sebuah
konsorsium yang terdiri dari perusahaan-perusahaan seperti

Microsoft Rational software

Oracle ICON computing
IBM MCI systemhouse
Hewlett-Packard Unisys Platinum Technology
Intellicorp Ptech
I-Logix Taskon and Reich Technologies
DEC, Digital Equipment Corp. Softeam
texas instrument
Sejarah UML (Unified Modeling Language)
 Dari konsorsium tersebut pada bulan Januari 1997 lahirlah UML versi 1.0
 Pada bulan September 1997 lahirlah UML versi 1.1, dengan 8 buah diagram, yaitu
 Use case diagram
 Activity diagram
 Sequence diagram
 Collaboration diagram
 Class diagram
 Statechart diagram
 Component diagram Grady Booch
Ivar Jacobson James Rumbaugh
 Deployment diagram
 Pada bulan November 1997 sebuah organisasi non profit standarisasi Object
Management Group (OMG) mengakui UML sebagai sebuah bahasa pemodelan
standar untuk aplikasi object oriented.
 OMG didirikan pada bulan April 1989 oleh sebelas perusahaan software, dengan
kantor pusat di Needham, MA, USA. (www.omg.org)
 Pada tahun 1999 lahirlah UML versi 1.3, menjadi 9 buah diagram, dengan
penambahan
› Business use case diagram
Sejarah UML (Unified Modeling Language)
 Pada May 2001 lahirlah UML versi 1.4, menjadi 10 buah diagram, dengan
penambahan
› Object Diagram
 Pada tahun 2002 lahirlah UML versi 2.0, menjadi 13 buah diagram,dengan
penambahan dan penggantian yaitu :
1. Use case diagram
2. Activity diagram
3. Sequence diagram
4. Communication Diagram (Collaboration diagram in versi 1.x)
5. Class diagram
6. State Machine Diagram (Statechart diagram in versi 1.x)
7. Component diagram
8. Deployment diagram
9. Composite Structure Diagram
10. Interaction Overview Diagram
11. Object Diagram
12. Package Diagram
13. Timing Diagram
● UML adalah bahasa model standar untuk
pengembangan cetak biru perangkat lunak.
● Bahasa model merupakan bahasa yang
memiliki kamus kata dan aturan yang berpusat
pada gambaran konseptual dan fisik dari suatu
sistem
● UML sebagai bahasa model menyatakan
bagaimana membuat dan membaca model
dengan benar, namun tidak menyatakan model
apa yang harus dibuat dan kapan seharusnya
dibuat
Peran UML
UML adalah bahasa untuk
● Visualisasi
Menggambarkan ide dalam notasi dan semantik
yang lebih mudah dipahami oleh siapapun
● Spesifikasi
Spesifikasi dari semua keputusan penting
analisa, perancangan, dan penerapan yang harus
diambil dalam pengembangan dan deployment
sistem PL
● Konstruksi
– UML bukan bahasa pemrograman visual
– Model UML dapat dihubungkan secara langsung
dengan beberapa bahasa pemrograman
– Forward engineering: menghasilkan kode dari model
– Reverse engineering: membangun model dari kode
● Dokumentasi
– UML mencakup dokumentasi arsitektur sistem dan
rincinya
– Sebagai suatu bahasa untuk menyatakan
kebutuhan dan pengujian.
– UML menyediakan bahasa untuk aktifitas
perencanaan proyek dan manajemen release
Blok Pembangun UML
● Thing
– “penghuni” paling elit dalam model
● Structural, Behavioral, Grouping, Annotations
● Relationship
– Menghubungkan antar thing
● Dependency, Association, Generalization,
Realization
● Diagram
– Kumpulan thing dan relationship
 Structural Things (1)
● Structural thing merupakan kata benda model
UML
– Class
● Gambaran dari sekumpulan objek yang berbagi atribut, operasi,
hubungan dan semantik yang sama
● Sebuah class menerapkan satu atau lebih antarmuka
– Interface
● Sekumpulan operasi yang menyatakan layanan suatu
class atau component
● Suatu interface menggambarkan perilaku objek yang
disediakan untuk pihak luar.
● Interface bisa saja menyatakan sebagian atau seluruh
perilaku suatu class/component.
● Collaboration
– Suatu interaksi dan suatu kumpulan aturan dan
elemen lain yang bekerja bersama untuk
perilaku yang bekerja sama
– Menyatakan penerapan pola yang membentuk sistem
● Use Case
– Suatu gambaran dari sekumpulan urutan aksi
yang terjadi pada sistem yang menghasilkan
suatu nilai kepada actor
– Digunakan untuk menstrukturkan perilaku sistem
dalam suatu model
– Merupakan realisasi dari collaboration.
● Active Class
– Suatu class dimana objek memiliki satu atau lebih
proses/thread sehingga dapat memulai aktifitas
kontrolnya
● Component
– Suatu bagian fisik dan replaceable dari suatu sistem
menyediakan realisasi dari sekumpulan antarmuka
– Menyatakan paket fisik daripada elemen logika,
seperti class, interface dan collaboration
● Node
– Elemen fisik yang ada pada saat run time dan
menyatakan suatu sesumber perhitungan, yang
memiliki memori dan kemampuan pemrosesan
 Behavioral Things
● Behavioral things merupakan bagian dinamis
dari model UML, yang menyatakan kata kerja
dari suatu model, menyatakan perilaku
sepanjang waktu dan ruang.
– Interaction: suatu perilaku yang terdiri dari
sekumpulan pertukaran pesan diantara sekumpulan
objek dalam suatu kontek untuk mencapai suatu
tujuan
– state machine: suatu perilaku yang menentukan
urutan state dari suatu objek atau interaksi
terhadap objek tersebut selama “hidup”nya.
Grouping Things
● Grouping things : bagian organisasional model UML.
● Package : mekanisme umum untuk
mengorganisasikan elemen-elemen ke dalam
kelompok-kelompok
– Structural things, behavioral things, dan
pengelompokan yang lain dapat ditempatkan dalam sebuah
package.
– Berbeda dengan component (yang ada selama run
time), package sepenuhnya konseptual (ada hanya pada
waktu pengembangan)
Annotations Things
● Annotational things : bagian model UML yang
memberikan keterangan.
– Note: suatu simbol yang memberikan batasan
dan komentar yang dikaitkan pada suatu
elemen atau kumpulan elemen
 Relationships
● Dependency
– Suatu hubungan semantik antara dua things
dimana perubahan pada satu thing (independent)
mungkin mempengaruhi semantik thing
(dependent) lain.
● Association
– Hubungan struktural yang menggambarkan
sehimpunan mata rantai antar objek.
– Aggregation merupakan bentuk association
khusus yang menyatakan hubungan struktural
antara whole dan part
● Generalization
– Hubungan spesialisasi dimana objek dari elemen
khusus (anak) merupakan pengganti untuk objek
elemen umum (induk)
● Realization
– Hubungan antara antarmuka yang tersedia
secara umum (interface atau use case)
dengan penerapan detail dari antarmuka
(class, package, atau use case realization).
 UML View

● Arsitektur dan perancangan sistem

memungkinkan kita untuk mengatur cara
pandang yang berbeda terhadap sistem dan
kontrol terhadap sistem keseluruhan
● UML memungkinkan kita untuk memodelkan
sistem untuk kepentingan berbagai cara pandang.
 Diagram-diagram UML (1)
● Business Use Case Diagrams
– Digunakan untuk menyatakan fungsionalitas yang
disediakan oleh suatu organisasi secara keseluruhan
– Digunakan secara intensif selama aktifitas
pemodelan bisnis untuk menghimpun kontek sistem
dan membentuk dasar pembuatan use case
– Tidak dibedakan antara proses manual atau
otomatis (use case fokus ke proses otomatis)
(dipandang dari sudut pandang organisasi)
– Business use case: proses fungsional bisnis
– Business actor: peran dimana bisnis berinteraksi
● Business Use Case Diagrams
– Kapan digunakan?
● Merupakan organisasi yang baru
● Sedang menjalankan dan atau sedang menerapkan
rekayasa ulang bisnis
● Membangun software yang berimbas pada bagian
penting perusahaan
● Terdapat workflow komplek yang tidak terdokumentasi
● Konsultan pada organisasi yang baru

– Kapan tidak perlu membuat Business Use Case?

● Sudah memahami visi, misi dan workflow organisasi
● Hanya membangun software yang tidak berimbas besar
pada organisasi
● Jika tidak tersedianya waktu.
Contoh Business Use Case
● Use Case Diagrams
– Memperlihatkan inetarksi antara use case dan
actor.
– Use cases mewakili fungsionalitas sistem,
kebutuhan sistem dari sudut pandang pemakai.
– Actors mewakili orang atau sistem yang
menyediakan atau menerima informasi dari
sistem.
Contoh Use Case
● Activity Diagram
– Menggambarkan aliran fungsionalitas dalam suatu
sistem.
– Dapat digunakan dalam pemodelan bisnis untuk
menunjukkan business workflow.
– Atau juga digunakan dalam analisa kebutuhan untuk
menggambarkan aliran kejadian melalui suatu use
case.
– Mendefinisikan dimana workflow dimulai, dimana
berhentinya, aktifitas apa yang terjadi selama
workflow, bagaimana urutan kejadian aktifitas
– Suatu aktifitas adalah suatu pekerjaan yang
dilaksanakan selama workflow
Contoh Activity Diagram
● Sequence Diagram
– Merupakan diagram interaksi yang menekankan
urutan waktu pertukaran pesan
● Collaboration Diagram
– Collaboration diagrams menampilkan informasi
yang sama dengan Sequence diagrams.
– Hanya saja, interaksi antara objek dan actor tidak
ditampilkan berdasar urutan waktu.
Contoh Sequence Diagram
Contoh Collaboration Diagram
● Class Diagram
– Memperlihatkan interaksi antar class dalam sistem.
– Class merupakan suatu cetak biru untuk objek
– Memperlihatkan gambaran statik dari class-class
dan hubungannya
● Statechart Diagram
– Menyediakan cara memodelkan berbagai state
keberadaan objek.
– Digunakan untuk memodelkan lebih dinamis
perilaku dari sistem
Contoh Class Diagram
Statechart Diagram
● Component Diagrams
– Memperlihatkan organisasi dan ketergantungan antara
sekumpulan komponen. (Implementation view)
– Dihubungkan dengan class diagram dimana komponen
tersebut memetakan satu atau lebih class, interface,
atau collaboration.
● Deployment Diagrams
– Memperlihatkan konfigurasi run-time pada node
pemrosesan dan komponen yang berjalan padanya.
– (static deployment view)
– Dihubungkan dengan component diagrams dimana
sebuah node menyertakan satu atau lebih komponen
Contoh Component Diagram
Deployment Diagram
 Pemakai model UML (1)
● Tidak hanya pengembang yang akan menggunakan UML
– Seluruh tim akan menggunakan Business Use
Case diagram untuk memahami bisnis dalam sistem.
– Pelanggan dan manajer proyek akan menggunakan
Use Case diagram untuk mendapat gambaran level
tinggi dari sistem dan menyetujui ruang lingkup
proyek.
– Manajer proyek akan menggunakan Use Case
diagram dan dokumentasi untuk membagi proyek
ke dalam sub proyek yang mudah diatur.
● Analis dan pelanggan akan meninjau dokumentasi use
case untuk melihat fungsi apa saja yang akan disediakan
oleh sistem.

● Penulis teknis akan melihat pada dokumentasi use case

untuk memulai menulis user manual dan rencana
pelatihan.

● Analis dan pengembang akan melihat Sequence dan

Collaboration diagram untuk mendapat gambaran
bagaimana aliran logika dalam sistem, objek dalam sistem
dan pertukaran pesan antar objek.

● Pegawai asuransi kualitas (QA) menggunakan

dokumentasi use case dan Collaboration diagram untuk
mendapatkan informasi yang mereka butuhkan untuk menguji script
● Pengembang menggunakan Class dan Statechart
diagram untuk mendapat gambaran detil sebagian
sistem dan bagaimana mereka menghubungkan.
● Pegawai Deployment menggunakan Component dan
Deployment diagram untuk melihat file executable,
DLL , atau komponen lain yang akan dibuat, dan
dimana komponen tersebut akan di-deploy pada
jaringan.
● Seluruh tim menggunakan model untuk memastikan
kebutuhan terselusuri ke kode program, demikian juga
sebaliknya.
 Mekanisme Umum dalam UML (1)

● Specification
– Setiap notasi grafik UML memiliki spefisikasi yang
merupakan pernyataan sintak dan semantiknya
● Adornment
– Setiap elemen dalam UML memiliki notasi grafik unik
yang menyediakan visualisasi aspek penting dari
elemen yang bersangkutan
● Common Division
– Pembagian antara class dan object
– Pemisahan antara interface dan implementasinya
● Extensibility Mechanism
– Stereotype
● Memperluas kamus kata UML, yang memungkinkan kita
membangun blok yang diturunkan dari yang sudah ada
namun khusus untuk masalah yang ada.
Contoh:
Exception pada Java/C++ yang sebetulnya sebuah class
yang memiliki fungsi khusus.
– Tagged Value
● Memperluas informasi dari spesifikasi elemen
– Constraint
● Memperluas semantik dari blok UML yang dibangun
 SELESAI