ENTI TY RELATI ONSHI P DI AGRAM, DATA FLOW DI AGRAM, COMPONENT

DI AGRAM

A. Pengertian Entity Relationship Diagram
Entity Relationship Diagram (ERD) adalah salah satu bentuk pemodelan data.
Sedangkan pemodelan data perlu dilakukan sebagai cara untuk menyusun dan
mengorganisasikan data sehingga dapat digunakan dengan mudah oleh database. ERD ini
menggambarkan data dalam konteks entitas dan hubungannya. Adapun Model Entity
Relationship diperkenalkan pertama kali oleh P.P. Chen pada tahun 1976. Model ini
dirancang untuk menggambarkan persepsi dari pemakai dan berisi obyek-obyek dasar yang
disebut entity dan hubungan antar entity-entity tersebut yang disebut relationship.
Tujuan utama Entity Relationship Diagram adalah untuk mendokumentasikan struktur
logis dari database, sehingga dengan adanya ERD memudahkan kita untuk melihat struktur
logis database.
B. Component Entity Relationship Diagram
Tabel 1. Komponen Entitas Relasi Diagam

1. Entity adalah obyek yang dapat dibedakan dengan yang lain dalam dunia nyata. Entity Set
adalah kumpulan dari entity yang sejenis.
2. Atribut adalah karakteristik dari entity atau relationship, yang menyediakan penjelasan
detail tentang entity atau relationship tersebut. Nilai Atribut merupakan suatu data aktual
atau informasi yang disimpan pada suatu atribut di dalam suatu entity atau relationship.
Ada beberapa jenis atribut, yaitu :
Key
Atribut yang digunakan untuk menentukan suatu entity secara unik.
Atribut Simple
Atribut yang bernilai tunggal.
Atribut Multivalue
Atribut yang memiliki beberapa kelompok nilai untuk setiap instan entity.
Atribut Komposit
Suatu atribut yang terdiri dari beberapa atribut yang lebih kecil yang mempunyai arti
tertentu.
Atribut Derivatif
Suatu atribut yang dihasilkan dari atribut yang lain
3. Relationship adalah hubungan yang terjadi antara satu atau lebih entity.
4. Kardinalitas Relasi menunjukkan jumlah maksimum entitas yang dapat berelasi dengan
entitas pada himpunan entitas lain.
Adapun macam-macam Kardinalitas:
Satu ke Satu (One to One)
Satu ke Banyak (One to Many)
Banyak ke Satu (Many to One)
Banyak ke Banyak (Many to Many)
C. Tahapan dalam membuat ERD :
1. Mengidentifikasi dan menetapkan seluruh himpunan entitas yang akan terlibat.
2. Menentukan atribut-atribut key dari masing-masing himpunan entitas.
3. Mengidentfikasi dan menetapkan seluruh himpunan relasi di antara himpunan entitas-
himpunan entitas yang ada beserta foreign key-nya.
4. Menentukan derajat/kardinalitas relasi untuk setiap himpunan relasi.
5. Melengkapi himpnan entitas dan himpunan relasi dengan atribut deskriptif ( bukan kunci
utama ).




D. Contoh Kasus:
Sebuah perusahaan mempunyai beberapa bagian. Masing-masing bagian mempunyai
pengawas dan setidaknya satu pegawai. Pegawai ditugaskan paling tidak di satu bagian
(dapat pula dibeberapa bagian). Paling tidak satu pegawai mendapat tugas di satu proyek.
Tetapi seorang pegawai dapat libur dan tidak dapat tugas di proyek.
1. Menentukan Entitas
Entitasnya : pengawas, bagian, pegawai, proyek
2. Menentukan Relasi Dengan Matrik Relasi
Tabel 2. Matrik Relasi

3. Hubungkan entitas sesuai dengan matrik relasi yang dibuat

Gambar 1. ERD Sementara
Gambar 1 merupakan gambar ERD sementara, hubungan dari entitas yang di
hubungkan menggunakan ralasi sehingga terbentuk relasi dari entitas bagian di jalankan
oleh pengawas, bagian juga di tugaskan ke pegawai, serta pegawai bekerja pada proyek.




4. Mengisi Kardinalitas
Dari gambaran permasalahan dapat diketahui bahwa:
Masing-masing bagian hanya punya satu pengawas.
Seorang pengawas bertugas di satu bagian.
Masing-masing bagian ada minimal satu pegawai.
Masing-masing pegawai bekerja paling tidak di satu bagian.
Masing-masing proyek dikerjakan paling tidak oleh satu pegawai.

Gambar 2. Mengisi Kardinalitas
Gambar 2 yaitu mengisi kardinalitas dari setiap relasi yang terbentuk, kardinalitas
yang terbentuk dari bagian ke pengawas yaitu one to one dimana satu bagian dijalankan
oleh satu pengawas. Kardinalitas yang terbentuk dari relasi bagian ke pegawai yaitu
many to many dimana banyak bagian bisa di tugaskan ke banyak bagian, serta ralasi dari
pegawai dan proyek membentuk kardinalitas many to many, banyak bekerja bisa bekerja
pada banyak proyek.










5. Menentukan Kunci Utama
Kunci utamanya: Nomor Pengawas, Nama Bagian, Nomor Pegawai, Nomor Proyek

Gambar 3. Menentukan Kunci Utama
Gambar 3 menentukan kunci utama, setelah member kardinalitas maka selanjutnya
adalah menentukan kunci utama atau primary key dari setiap entitas yang telah
terhubung, pada entitas terdapat kunci utama nama bagian, entitas pengawas terdapat
kunci utama nomor pengawas, entitas pegawai terdapat kunci utama nomor pegawai,
serta entitas proyek memiliki kunci utama nomor proyek.
6. Menggambar ERD Berdasarkan Kunci
Ada dua relasi many to many pada ERD sementara, yaitu antara bagian dengan
pegawai, pegawai dengan proyek, oleh sebab itu kita buat entitas baru yaitu bagian -
pegawai dan pegawai-proyek Kunci utama dari entitas baru adalah kunci utama dari
entitas lain yang akan menjadi kunci tamu di entitas yang baru.

Gambar 4. Menggambar ERD Berdasarkan Kunci
Gambar 4 membuat ERD berdasarkan kunci utama, setiap kunci utama dari entitas
menjadi satu kunci utama dalam ERD, relasi yang terbentuk dari kardinalitas many to
many membentuk satu entitas baru, entitas yang terbentuk memiliki kunci utama dari
setiap entitas yang terbentuk, contohnya yaitu relasi yang terbentuk dari pegawai dan
proyek membentuk satu entitas baru yang mengambil kunci utama dari masing masing
entitas yang berfungsi sebagai kunci tamu.
7. Menentukan Atribut
Atribut yang diperlukan adalah: nama bagian, nama proyek, nama pegawai, nama
pengawas, nomor proyek, nomor pegawai, nomor pengawas
8. Memetakan Atribut
Bagian : Nama bagian
Proyek: Nama proyek
Pegawai:Nama pegawai
Pengawas: Nama pengawas
Proyek-Pegawai : Nomor proyek, Nomor pegawai
Pengawas: Nomor pengawas
9. Menggambar ERD dengan atribut

Gambar 5. Menggambar ERD Dengan Atribut


Gambar 5 menggambar ERD dengan atribut, sama seperti menggambar ERD dengan
Kunci Utama tetapi lebih menekankan pada atribut dari setiap entitas, di mana setiap
entitas memiliki atribut-atribut bukan kunci, dan pada gambar ini di sertakan atribut-
atribut yang bukan kunci untuk di sertakan dalam keterangan ERD.
10. Memeriksa Hasil
Periksa apakah masih terdapat redundasi. ERD akhir: untuk pemodelan data pada sistem.
E. Data Flow Diagram(DFD)
DFD merupakan alat perancangan sistem yang berorientasi pada alur data dengan
konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan
sistem yang mudah dikomunikasikan oleh professional system kepada pemakai maupun
pembuat program.
F. Komponen Data Flow Diagram
Menurut Yourdan dan DeMarco

Gambar 6. Komponen Data Flow Diagram
Menurut Gene dan Serson

Gamabr 7. Komponen Data Flow Diagram
1. Terminator / Entitas Luar
Adalah Entitas diluar sistem yang berkomunikasi / berhubungan langsung
dengan sistem.
Terdapat 2 jenis Terminator :
a. Terminator Sumber
Merupakan Terminator yang menjadi sumber
b. Terminator Tujuan
Merupakan Terminator yang menjadi tujuan data atau informasi sistem.

Gambar 8. Terminator
Terminator dapat berupa orang, sekelompok orang, organisasi, perusahaan atau
departemen yang berada diluar sistem yang akan dibuat, diberi nama yang berhubungan
dengan sistem tersebut dan biasanya menggunakan kata benda.
Contoh : Dosen, Mahasiswa.
Hal yang perlu diperhatikan tentang terminator :
a. Alur data yang menghubungkan terminator dengan sistem, menunjukkan hubungan
sistem dengan dunia luar.
b. Profesional sistem tidak dapat mengubah isi atau cara kerja, prosedur yang
berkaitan dengan terminator.
c. Hubungan yang ada antar terminator tidak digambarkan dalam DFD.

2. Komponen Proses
Komponen proses menggambarkan transformasi input menjadi output.
Pemberian nama proses disesuaikan dengan proses atau kegiatan yang sedang
dilakukan.
Ada 4 kemungkinan yang dapat terjadi dalam proses berhubungan dengan input dan
output :

Gambar 9. Komponen Proses
Ada beberapa hal yang perlu diperhatikan tentang proses :
a. Proses harus memiliki input dan output.
b. Proses dapat dihubungkan dengan komponen terminator, data store atau proses
melalui alur data.
c. Sistem (bagian divisi departemen) yang sedang dianalisis oleh professional system
digambarkan dengan komponen proses.
3. Komponen Data Store
Komponen ini digunakan untuk membuat model sekumpulan paket data dan
diberi nama dengan kata benda bersifat jamak. Data Store dapat berupa file atau database
yang tersimpan dalam flopy disk, harddisk atau bersifat manual seperti buku alamat, file
folder.
Yang perlu diperhatikan tentang data store :
a. Alur data dari proses menuju data store, hal ini berarti data store berfungsi sebagai
tujuan atau tempat penyimpanan dari suatu proses (process write).
b. Alur data dari data store ke proses, hal ini berarti data store berfungsi sebagai
sumber atau proses memerlukan data (process read).
c. Alur data dari proses menuju data store dan sebaliknya berarti berfungsi sebagai
sumber dan tujuan.

Gambar 10. Komponen Proses Data Store
4. Komponen Alur Data
Alur data digunakan untuk menerangkan perpindahan data atau paket data dari
satu bagian ke bagian lainnya. Alur data dapat berupa kata, pesan, formulir atau
informasi.
Ada 4 konsep tentang alur data :
1. Packets of Data
Apabila ada 2 data atau lebih yang mengalir dari 1 sumber yang sama menuju
pada tujuan yang sama dan mempunyai hubungan digambarkan dengan 1 alur

Gambar 11. Packet Data
2. Diverging Data Flow
Apabila ada sejumlah paket data yang berasal dari sumber yang sama menuju
pada tujuan yang berbeda atau paket data yang kompleks dibagi menjadi beberapa
elemen data yang dikirim ke tujuan yang berbeda.

Gambar 12. Diverging Data Flow
3. Converging Data Flow
Apabila ada beberapa alur data yang berbeda sumber menuju ke tujuan yang sama.

Gambar 13. Converging Data Flow
5. Sumber dan Tujuan
Arus data harus dihubungkan pada proses, baik dari maupun yang menuju proses.

Gambar 14. Arus Data

G. Contoh Data Flow Diagram

Gambar 15. Konteks Diagram Sistem Penggajian
1. Bagian pegawai dan bagian direktur memberikan data kepada bagian penggajian. Bagian
pegawai memberikan data karyawan sedangkan bagian direktur memberikan data berupa
data jabatan, data upah lembur, dan data upah perjam. Kemudian data tersebut
dimasukkan dalam bagian keuangan untuk di proses.
2. Setelah data data tersebut masuk dalam bagian penggajian, setelah di proses, kemudian
bagian penggajian memberikan laporan data karyawan ke dalam bagian personalia untuk
direkap.
3. Setelah data direkap, bagian personalia memberikan data rekap karyawan ke bagian
penggajian.
4. Kemudian setelah dari bagian keuangan, data tersebut diberikan kepada bagian direktur
untuk diperiksa lagi.
5. Setelah proses pemeriksaan selesai, dan jika semua data sudah benar, maka bagian
pengajian akan memeberikan slip gaji kepada para pegawai.

Gambar 16. Dekomposisi Sistem Penggajian
Di dalam sistem informasi penggajian, ada 3 proses penting, yaitu : pencatat data,
perhitungan gaji karyawan dan pembutan laporan.
Dalam proses pencatatan data di pecah lagi menjadi beberapa proses yaitu:
Pendataan karyawan.
Pendataan jabatan.
Pendataan upah perjam dan lembur.
Dalam proses perhitungan gaji karyawan di pecah lagi menjadi beberapa proses yaitu :
Hitung gaji.
Cetak slip.

Dalam proses pembuatan laporan di pecah lagi menjadi beberapa proses yaitu:
Pembuatan laporan karyawan.
Pembuatan laporan gaji.

Gambar 17. DFD Level 0 Sistem Penggajian
1. Bagian karyawan dan bagian direktur memberikan data. Bagian karyawan memberikan
data karyawan, bagian direktur memberikan data jabatan, data upah perjam, dan data
upah lembur. Data data tersebut diberikan kepada bagian pencatatan data.
2. Kemudian setelah dilakukan pencatatan data, kemudian data tersebut di berikan kepada
bagian perhitungan gaji karyawan, untuk melakukan proses perhitungan gaji.
3. Kemudian setelah melalukan proses perhitungan gaji, data akan dikirim ke bagian
pembuatan laporan, untuk merevisi apakah laporan sudah benar atau belum.
Jika laporan ada terjadi data yang salah maka data tersebut akan diserahkan ke bagian
personalia. Di bagian personalia laporan data-data yang salah akan direkap kembali.
Setelah proses rekap data selesai, kemudian data akan dikirim ke bagian perhitungan gaji
untuk di periksa kembali.

4. Setelah data diperiksa di bagian perhitungan gaji, kemudian data akan dikirim ke
pembuatan laporan. Kemudian hasilnya akan di serahkan ke bagian direktur untuk di
periksa. Jika semua data sudah benar dan memenuhi syarat, maka pada bagian
perhitungan gaji akan memberikan slip gaji kepada karyawan.

Gambar 18. DFD Level 1 Proses 1 Pencatatan Data
Pada proses DFD Level 1 Proses 1, terdapat 3 proses yaitu data karyawan dan data jabatan,
serta upah perjam dan lembur, pada proses data karyawan terdapat beberapa alur, yang
pertama data di masukkan oleh karyawan yang kemudian diproses oleh system, selain itu
terdapat proses data jabatan dan proses upah perjam yang di lakukan oleh direktur, direktur
memasukkan data upah per jam dan data jabatan dimana upah per jam di simpan ke dalam
tabel upah dan data jabatan di simpan ke tabel jabatan, karyawan mengambil data jabatan
untuk diproses ke data karyawan, kemudian di simpan ke dalam tabel karyawan.

Gambar 19. DFD Level 1 Proses 2 Perhitungan Gaji Karyawan
Proses perhitungan gaji karyawan terdapat dua proses, yaitu hitung gaji dan cetak slip,
proses ini di lakukan oleh personalia dengan memasukkan rekap data absensi dan lembur,
selain itu mengambil data karyawan, data upah, data jabatan yang dip roses kemudian di
simpan ke tabel slip, setelah itu dilanjutkan proses cetak slip dengan mengambil data slip,
upah serta jabatan yang diproses dan setelah itu proses tersebut di cetak untuk di berikan ke
karyawan.

Gambar 20. DFD Level 1 Proses 3 Pembuatan Laporan
Proses pembuatan laporan, terdapat dua proses, yang pertama proses laporan data karyawan,
mengambil data slip, jabatan, upah, karyawan yang dip roses kemudian di laporkan ke
personalia, proses yang kedua yaitu laporan gaji karyawan yang mengambil data dari data
slip, jabatan, upah, karyawan kemudian diproses menjadi laporan. Kedua proses
menghasilkan laporan yang akan di berikan kepada direktur.

H. Component Diagram
Component Diagram adalah diagram UML yang menampilkan komponen dalam
system dan hubungan antara mereka. Pada component view, akan difokuskan pada organisasi
fisik system. Pertama, diputuskan bagaimana kelas-kelas akan diorganisasikan menjadi kode
pustaka. Kemudian akan dilihat bagaimana perbedaan antara berkas eksekusi, berkas
dynamic link library (DLL), dan berkas runtime lainnya dalam system.




I. Tipe Tipe Komponen
Komponen adalah modul fisik dari kode. Komponen dapat mencantumkan pustaka
kode program dan berkas - berkas runtime sekaligus. Misalnya, jika kita menggunakan
C++, setiap berkas (.cpp dan .h) adalah komponen berbeda. Berkas-berkas (.exe) yang anda
ciptakan setelah kode program di compile juga termasuk komponen.
Sebelum menjalankan kode, petakan setiap berkas kepada komponen yang tepat.
Pada C++, setiap kelas dipetakan kedua komponen. Satu mewakili berkas (.cpp) untuk kelas
tersebut dan yang lainnya mewakili berkas (.h). Pada Java kita petakan setiap kelas
komponen tunggal, mewakili berkas (.java) untuk kelas tersebut. Ketika kita
membangkitkan kode, Rational Rose akan menggunakan komponen informasi untuk
menciptakan berkas-berkas kode pustaka yang tepat.
Ketika komponen sudah tercipta, akan ditambahkan ke diagram komponen dan
hubungan yang terjadi antar mereka. Satu-satunya tipe hubungan antar komponen adalah
dependensi. Despendensi menyatakan bahwa satu komponen harus di compile sebelum yang
lainnya. Beberapa tipe komponen sebagai berikut :
1. Component
Notasi-notasi komponen mempresentasikan module perangkat lunak dengan
sebuah antar muka yang di devinisikan dengan baik. Para spesifikasi komponen, kita
dapat menspesifikasi tipe komponen dalam kolom stereotype ( Active X, Applet, Aplikasi,
DLL, Executable). Dalam UML, notasi keadaan digambarkan sebagai berikut.

Gambar 21. Generic Component
2. Sub-Program Specification and Body
Notasi ini mempresentasikan spesifikasi subprogram yang terlihat dan bagian
implementasi. Subprogram secara tipikal adalah kumpulan beberapa subroutine.
Subprogram tidak berisi devinisi kelas.


Gambar 22. Sub-Program Specification and Body
3. Main Program
Notasi ini mempresentasikan program utama. Program utama adalah berkas yang
berisi root program. Contoh, pada power builder, ada berkas yang berisi obyek aplikasi.

Gambar 23. Main Program
4. Package Specification and Body
Sebuah paket atau package adalah implementasi kelas. Sebuah paket spesifikasi
adalah berkas header, yang berisi informasi fungsi prototype untuk kelas. Di C++,
spesifikasi paket adalah berkas (.h). Di Java, kita menggunakan notasi paket spesifikasi
untuk mempresentasikan berkas (.java). Sebuah package body berisi kode untuk operasi-
operasi dari kelas. Di C++, package body adalah berkas (.cpp).

Gambar 24. Package Specification and Body
Ada notasi tambahan yang digunakan untuk komponen runtime termasuk berkas-
berkas executable, berkas DLL, dan beberapa task lainnya.



5. Task Specification and Body
Notasi-notasi ini mempresentasikan paket yang memiliki thread control yang
berdiri sendiri. Berkas executable biasanya mempresentasikan spesifikasi task dengan
ekstensi (.exe).

Gambar 25. Task Specification and Body
6. Database
Notasi ini mempresentasikan sebuah basis data, yang berisi satu atau beberapa
skema. Pada komponen diagram, basis data ditunjukkan seperti ini :


Gambar 26. Database

I. Detail Komponen
Ada sejumlah detail spesifikasi yang ditambahkan ke setiap komponen. Ini termasuk
stereotype, bahasa, deklarasi, dan kelas-kelas.
1. Stereotype
Stereotype mengatur notasi yang akan digunakan untuk mempresentasikan
komponen. Strereotype adalah yang menggunakan notasi komponen, spesifikasi
subprogram, subprogram body, program utama, paket spesifikasi, package body,
executable, DLL, spesifikasi task, dan task body.

Rational Rose memasukkan sejumlah stereotype yang lain untuk bahasa
pemrograman yang berbeda. Stereotype bahasa pemrograman lainnya, dapat dilihat pada
tabel :
Tabel 3. Stereotype
BahasaPemrograman Stereotype
Java EJBDeploymentDescriptor, EJB JAR,
ServletDeploymentDescription, dan WAR
Oracle 8 Database, Schema
Visual Basic ActiveX Control

Kita dapat menambahkan stereotype tambahan jika ingin mempresentasikan tipe
komponen baru pada bahasa pemrograman yang akan digunakan.
2. Bahasa Pemrograman
Kita dapat menandai bahasa pemrograman pada komponen-komponen dasar. Jadi,
dapat dibangkitkan satu bagian model di C++, bagian lainnya di Java, bagian lainnya di
Visual Basic dan sebagainya.
Rose Enterprise berisi tambahan untuk ANSI C++, Ada 83, Ada 95, CORBA,
C++, Java, Visual basic, Visual C++, Web modeler, XML/DTD, Dan Oracle 8. Ada
banyak lagi tambahan tersedia dari beberapa vendor untuk memperluas kemampuan
Rose. Untuk bahasa pemrograman lain (Power Builder, Forte, Visual Age for Java, dll)
mungkin akan dipesan juga.
3. Deklarasi
Ada bagian untuk mencantumkan deklarasi pelengkap yang ditambahkan pada
saat generate code untuk setiap komponen. Deklasrasi termasuk bahasa pemrograman
pernyataan spesifik yang digunakan untuk mendeklarasi variable, kelas-kelas, dan
sebagainya. Pernyataan #include kepada C++ juga termasuk deklarasi ini.
4. Kelas-kelas
Sebelum mengenerate kode untuk sebuah kelas, maka harus dipetakan
kekomponen. Pemetaan ini membantu Rational Rose mengetahui kelas-kelas mana saja
yang akan dipetakan dalam berkas fisik kode.




J. Dependensi Komponen
Hanya ada 1 tipe relasi antar komponen yaitu dependensi. Dependensi menyatakan
bahwa satu komponen bergantung pada lainnya. Sebuah dependensi digambarkan seperti
panah putus-putus antara 2 komponen.

Gambar 27. Dependensi Komponen
Pada gambar 26, komponen A bergantung pada komponen B. dengan kata lain ada
satu atau beberapa kelas di A yang bergantung pada satu atau beberapa kelas di B.
Dependensi memiliki implikasi komplikasi, dimana komponen A tergantung pada
komponen B. A tidak dapat di - compile sampai B telah selesai di-compile. Seseorang yang
membaca diagram ini akan mengetahui bahwa B harus di-compile terlebih dahulu, kemudian
dilanjutkan dengan A.
Bagaimana jika terjadi dependensi memutar (circular dependency)? jika terjadi hal
tersebut, komponen A bergantung pada komponen B dan komponen B bergantung pada
komponen A, maka komponen A atau B tidak dapat di-compile sampai salah satu di-
compile. Salah satu penyelesaian yang tepat untuk hal tersebut adalah menjadikan keduanya
komponen yang lebih besar. Cara lain yang di sarankan adalah memecah salah satu
komponen yang lebih besar, atau dengan cara memecah salah satu komponen menjadi dua
komponen dimana dependensi memutar dihapuskan. Apapun solusi yang diambil yang jelas
adalah bahwa semua dependensi memutas harus dihapuskan sebelum generate code
dilakukan.









H. Contoh Component Diagram
Gambar 28. Contoh Component Diagram
Penjelasan:
Kendaraan masuk
Saat kendaraan masuk area parkir, kamera CCTV mengambil gambar nomor
kendaraan, lalu pengendara menekan tombol ambil karcis, kemudian mesin mengeluarkan
karcis, kemudian pengendara mengambil karcis, dan kamera CCTV menyimpan data
kendaraan ke dalam database. Setelah pengendara mengambil karcis, pintu palang terbuka
dan pengendara masuk dan parkir kendaraan.
Kendaraan keluar
Pengendara memberikan karcis kepada pegawai mesin kasir. Lalu pegawai tersebut
mengecek data masuk kendaraan, setelah mengecek kemudian kasir menghitung total biaya
parkir. Kemudian pengendara membayar biaya parkir. Setelah pengendara membayar, lalu
palang terbuka dan pengendara keluar dari area parkir.




Daftar Pustaka

http://id.scribd.com/doc/47238622/Pengertian-ERD
agusdar.files.wordpress.com/2013/03/dfd.pdf
http://mahergabayu.blogspot.com/2011/01/component-deployment-diagram.html
http://mrofiuddin.blogspot.com/2011/11/pengertian-component-diagram-dalam-uml.html