KATA PENGANTAR
Alhamdulillah, segala puji dan syukur penulis panjatkan kehadirat Allah Subhaanahuwata’ala karena buku ini telah selesai disusun. Buku ini disusun agar dapat membantu para mahasiswa dalam mempelajari ilmu data modelling beserta mempermudah mempelajari materi data modelling terutama bagi kaum awam yang belum data modelling itu sendiri.
Penulis pun menyadari jika didalam penyusunan buku ini mempunyai kekurangan, namun penulis meyakini sepenuhnya bahwa sekecil apapun buku ini tetap akan memberikan sebuah manfaat bagi pembaca.
Akhir kata untuk penyempurnaan buku ini, maka kritik dan saran dari pembaca sangatlah berguna untuk penulis kedepannya.
Depok, 20 Februari 2020
Penulis
DAFTAR ISI
Kata Pengantar
Daftar Isi
Daftar Gambar
BAB 1. PERMODELAN DATA
1.1 Data Model
BAB 2. Entity Relationship Diagram
2.1 ERD
2.2 Entitas Kuat
2.3 Entitas Lemah
2.4 Agregasi
2.5 Atribut
2.6 Hubungan Relasi
BAB 3. DATA FLOW DIAGRAM
3.1 Konsep Perancangan Terstruktur
3.2 Data Flow Diagram (DFD)
3.3 Komponen Data Flow Diagram
3.4 Bentuk Data Flow Diagram
3.5 Syarat-syarat Pembuatan DFD
3.6 Penggambaran DFD
BAB 4. SPESIFIKASI PROSES
BAB 5. DATA DICTIONARY
BAB 6. MASA DEPAN PEMODELAN DATA
6.1 Pemodelan Data
6.2 Proses Pemodelan Data Logis
BAB 7. PENUTUP
7.1 Kesimpulan
7.2 Saran
DAFTAR PUSTAKA
DAFTAR GAMBAR
BAB 1. PERMODELAN DATA
1.1.1 Model Data Hirarkis
1.1.2 Model data jaringan
1.1.3 Model Data Relasional
1.1.4 Model Data Berbasis Objek
BAB 2. Entity Relationship Diagram
2.1.1 Contoh gambar dari ERD
2.1.2 Arti Simbol ERD
2.3.1 gambar contoh entitas lemah dan kuat
2.4.1 Agregasi
2.5.1 Simbol untuk membuat diagram ERD
2.5.2 contoh kasus 1 ERD
2.5.3 Relationship
2.5.4 Atribut Multivalue
2.5.5 Atribut Multivalue
2.5.6 Derajat dari Relationship
2.5.7 Cardinality Ratio Constraint
2.5.8 Participation Constraint
2.5.9 Diagram ERD
2.5.10 Contoh Kasus 2
BAB 3. DATA FLOW DIAGRAM
3.3.1 DFD menurut Yourdan dan DeMarco
3.3.2 Komponen Terminator
3.3.3 komponen proses
3.3.4 contoh proses yang salah
3.3.5 alur data dari dan ke
3.3.6 Konsep Paket Data
3.3.7 Konsep Alur Data Menyebar (DDF)
3.3.8 Konsep Alur Data Mengumpul (CDF)
3.3.9 Konsep Sumber atau Tujuan Alur Data
3.4.1 (a) Diagram Alur Data Logika
3.4.2 (b) Diagram Alur Data Fisik
3.5.1 Pemberian No pada Komponen Proses
3.5.2 Alur data melingkar dan alur data lurus
3.5.3 Penghindaran gambaran DFD yg rumit
3.6.1 Penggambaran DFD
BAB 6. MASA DEPAN PEMODELAN DATA
6.1.1 Motherboard
6.1.2 Himpunan gabungan data modelling
6.1.3 Pemodelan Data
6.1.4 Sub Data Modelling
6.1.5 Pemodelan Data
6.1.6 Pemodelan Data
6.2.1 Proses Pemodelan Data Logis
6.2.2 Use Case Diagram
6.2.3 Activity Diagram
6.2.4 Package Diagram
6.2.5 State Machines Diagram
6.2.6 Sequence Diagram
6.2.7 Class Diagram
6.2.8 Communication Diagram
6.2.9 Composite Structure Diagram
6.2.10 Object Diagram
6.2.11 Timing Diagram
6.2.12 Component Diagram
6.2.13 Deployment Diagram
6.2.14 Interaction Overview Diagram
BAB 1. PERMODELAN DATA
Pemodelan Data dalam rekayasa perangkat lunak adalah proses menciptakan sebuah model data dengan menerapkan model deskripsi formal data menggunakan teknik pemodelan data. Pemodelan data adalah metode yang digunakan untuk menentukan dan menganalisis persyaratan data yang diperlukan untuk mendukung proses bisnis suatu organisasi. Data yang dibutuhkan adalah dicatat sebagai data model konseptual dengan definisi data yang terkait.
Realisasi penerapan model konseptual yang disebut model data logis. Untuk menerapkan satu model konseptual data mungkin membutuhkan beberapa model data logis. pemodelan data mendefinisikan elemen tidak hanya data, tapi struktur dan hubungan antara mereka teknik pemodelan data dan metodologi yang digunakan untuk model data dengan cara yang standar yang konsisten, dapat diprediksi untuk mengelolanya sebagai sumber daya.
Penggunaan standar pemodelan data sangat disarankan untuk semua proyek yang membutuhkan standar sarana untuk mendefinisikan dan menganalisis data dalam sebuah organisasi, misalnya dengan menggunakan pemodelan data: Untuk mengelola data sebagai sumber daya; Untuk integrasi sistem informasi; Untuk merancang database / data warehouse (alias repositori data). Pemodelan data dapat dilakukan pada berbagai jenis proyek dan dalam beberapa tahap proyek. Data model progresif, tidak ada hal seperti model data akhir untuk bisnis atau aplikasi. Sebaliknya model data harus dianggap sebagai dokumen hidup yang akan berubah sebagai respons terhadap perubahan bisnis. Model data idealnya harus disimpan dalam repositori sehingga mereka dapat diambil, dikembangkan, dan diedit dari waktu ke waktu.
Pengertian Data Modelling (Pemodelan Data) menurut Para Ahli. Adapun definisi Data Modelling (Pemodelan Data) Lainnya Termasuk:
a. Data Management Body of Knowledge (DMBOK)
Menurut Data Management Body of Knowledge (DMBOK), Data Modelling (Pemodelan Data) adalah Proses menemukan, menganalisis, mewakili, dan mengkomunikasikan persyaratan data dalam bentuk yang tepat disebut Data Model (Model Data).” dan “Data Model (Model Data) menggambarkan dan memungkinkan suatu organisasi untuk memahami aset datanya.
b. Technopedia
Berdasarkan situs Technopedia, pengertian Data Modelling (Pemodelan Data) adalah representasi dari struktur data dalam tabel untuk basis data perusahaan dan merupakan ekspresi yang sangat kuat dari persyaratan bisnis perusahaan. Data Model (Model Data) ini adalah panduan yang digunakan oleh analis fungsional dan teknis dalam desain dan implementasi database.
c. Agile Data
Menurut Agile Data, pengertian Data Modelling (Pemodelan Data) adalah tindakan mengeksplorasi struktur berorientasi data. Seperti artefak pemodelan lainnya, Data Model (Model Data) dapat digunakan untuk berbagai tujuan, dari model konseptual tingkat tinggi hingga Data Model (Model Data) fisik. Dari sudut pandang Data Modelling (Pemodelan Data) pengembang berorientasi objek secara konseptual mirip dengan pemodelan kelas. Dengan Data Modelling (Pemodelan Data) Anda mengidentifikasi tipe entitas sedangkan dengan pemodelan kelas Anda mengidentifikasi kelas.
Whitten (2004) ditetapkan dua jenis data model:
1. Data Strategis pemodelan:
Ini adalah bagian dari penciptaan strategi sistem informasi, yang menetapkan visi keseluruhan dan arsitektur sistem informasi didefinisikan. teknik Informasi adalah metodologi yang mencakup pendekatan ini.
2. Pemodelan Data dalam analisis sistem:
Dalam analisis sistem model data logis dibuat sebagai bagian dari pengembangan basis data baru. Pemodelan Data juga merupakan teknik untuk merinci kebutuhan bisnis untuk database. Kadang-kadang disebut pemodelan database karena model data akhirnya diimplementasikan dalam database.
1.1 Data model
Data model ataupun model data dan data pendukung sistem komputer dengan memberikan definisi dan format data. Jika hal ini dilakukan secara konsisten di seluruh sistem lalu kompatibilitas data dapat dicapai. Jika struktur data yang sama yang digunakan untuk menyimpan dan mengakses data kemudian aplikasi yang berbeda dapat berbagi data. Hasil ini ditunjukkan di atas.
Namun, sistem dan antarmuka sering biaya lebih dari yang seharusnya, untuk membangun, mengoperasikan, dan memelihara. Mereka juga dapat membatasi bisnis dan bukan mendukungnya. Penyebab utama adalah bahwa kualitas model data yang diimplementasikan dalam sistem dan antarmuka yang miskin.
1. Bisnis aturan, khusus untuk bagaimana hal tersebut dilakukan di tempat tertentu, yang sering tetap dalam struktur model data. Ini berarti bahwa perubahan kecil dalam cara bisnis dilakukan menyebabkan perubahan besar dalam sistem komputer dan interface.
2. Jenis Entitas sering tidak teridentifikasi, atau salah diidentifikasi. Hal ini dapat mengakibatkan replikasi data, struktur data, dan fungsionalitas, bersama-sama dengan biaya petugas itu duplikasi dalam pembangunan dan pemeliharaan.
3. Model data untuk sistem yang berbeda sewenang-wenang yang berbeda. Hasil ini adalah bahwa interface yang kompleks diperlukan antara sistem yang berbagi data. Interface ini dapat menjelaskan antara 25-70% dari biaya sistem saat ini.
4. Data tidak dapat dibagi secara elektronik dengan pelanggan dan pemasok, karena struktur dan arti data yang belum standar. Sebagai contoh, data desain teknik dan gambar untuk pabrik pengolahan masih kadang-kadang dipertukarkan pada kertas.
Jenis Data Model (Model Data) Ada terutama tiga jenis Data Model (Model Data) dalam Data Modelling (Pemodelan Data) yaitu adalah sebagai berikut:
a. Konseptual
Data Model (Model Data) ini mendefinisikan APA yang berisi sistem. Model ini biasanya dibuat oleh pemangku kepentingan Bisnis dan Arsitek Data. Tujuannya adalah untuk mengatur, memperluas, dan mendefinisikan konsep dan aturan bisnis.
b. Logis
Menentukan bagaimana sistem harus diimplementasikan terlepas dari DBMS. Model ini biasanya dibuat oleh Arsitek Data (dalam Data Architecture) dan Analis Bisnis. Tujuannya adalah untuk mengembangkan peta teknis peraturan dan struktur data.
c. Fisik
Data Model (Model Data) ini menjelaskan BAGAIMANA sistem akan diimplementasikan menggunakan sistem DBMS tertentu. Model ini biasanya dibuat oleh DBA dan pengembang. Tujuannya adalah implementasi aktual dari database.
Ada sejumlah cara dalam merepresentasikan Model Data untuk keperluan perancangan basis data, yaitu dikelompokkan sebagai berikut:
1. Model Hirarkis (Hierarchical Model)
2. Model Jaringan (Network Model)
3. Model Relasional (Relational Model)
4. Model Relasi Entitas (Entity-Relationship Model)
5. Model Berbasis Objek (Object Oriented Model)
1) Model Data Hirarkis
Model data hirarkis adalah model data paling tua yang pernah diterapkan dalam suatu DBMS. Model ini mengikuti pola hirarki pada suatu organisasi atau pada suatu keluarga, dimana terdapat rekaman data yang berfungsi sebagai “bapak” (parent-record) ada yang berfungsi sebagai “anak” (child-record). Dalam model ini seorang “bapak” bisa memiliki lebih dari satu “anak” tetapi seorang “anak” hanya boleh memiliki satu “bapak”.
Contoh model hirarkis yang menunjukkan hubungan Dosen-MataKuliah-Mahasiswa dapat digambarkan dalam bentuk diagram sebagai berikut :
Gambar 1.1.1
• Kelebihan menggunakan model hirarki
Ada beberapa kelebihan dari penggunaan model data hirarki, yaitu:
a) Data akan dengan cepat bisa dilakukan retrieve
b) Integritas antar data akan lebih mudah diatur sesuai dengan keperluan
• Kelemahan model hirarki
Sementara untuk kelemahannya antara lain:
a) Seseorang yang menggunakan model ini harus benar-benar familiar terhadap susunan basis data.
b) Akan terjadi redudansi data
2) Model data jaringan
Model data jaringan adalah pengembangan dari model data hirarkis. Pada model jaringan diperkenankan bahwa sebuah child-record bisa memiliki lebih dari satu parent-record.
Pada implementasi-nya berarti antara parent-record dan child-record diperlukan penghubung (link atau pointer) yang bisa satu arah atau dua-arah. Model Jaringan dari Dosen-Matakuliah-Mahasiswa dapat digambarkan sebagai berikut.
Gambar 1.1.2
Persoalan yang timbul adalah “terjadinya hutan pointer” akibat relasi antar record yang rumit sehingga penelusuran data menjadi sangat sulit. Ketika model relasional menjadi lebih populer maka model ini pun ditinggalkan orang.
• Kelebihan menggunakan model data jaringan
a) Data yang mudah diakses
b) Kemudahan ketika hendak memodelkan basis data yang bersifat kompleks.
c) Bisa dengan mudah ketika hendak membentuk query yang kompleks di dalam retrieve data.
• Kekurangan model data jaringan
a) Struktur datanya yang tidak mudah ketika hendak melakukan modifikasi
b) Pengguna harus benar-benar memahami seperti apa struktur datanya
3) Model Data Relasional
Salah seorang pencetus awal dari basis data relasional adalah E.F.Codd yang juga telah menciptakan serangkaian operasi matematika relasional terhadap model data relasional.
Contoh: domain mahasiswa dapat diwakili oleh satu tabel mahasiswa dengan kunci utama adalah NIM (Nomor Induk Mahasiswa), dan domain matakuliah dapat diwakili oleh satu tabel kuliah dengan kunci utama kode-mkuliah.
Gambar 1.1.3
Hubungan antara kedua domain ini dinyatakan dalam bentuk relasi, ada tiga kemungkinan relasi antar dua domain yaitu:
1. Relasi satu-satu (one-to-one relation) : bahwa satu mahasiswa hanya boleh mengambil satu matakuliah, dan satu matakuliah hanya boleh diambil oleh satu mahasiswa, relasi disingkat dengan simbol 1-to-1. Dalam implementasi dua file yang memiliki relasi 1-to-1 dapat digabung menjadi satu file.
2. Relasi satu-banyak (one-to-many relation) : bahwa satu mahasiswa boleh ambil banyak matakuliah tetapi satu matakuliah hanya boleh diambil oleh satu mahasiswa, relasi disingkat dengan simbol 1-to-M atau M-to-1. Pada relasi 1-to-M atau M-to-1, kunci record dari file pada sisi-1 harus ditambahkan sebagai kunci-tamu pada file sisi-M
3. Relasi banyak-banyak (many-to-many relation) : bahwa satu mahasiswa boleh ambil banyak matakuliah, dan satu matakuliah boleh diambil oleh banyak mahasiswa, relasi disingkat dengan simbol M-to-M. Pada relasi M-to-M harus diciptakan sebuah file ‘relasi’ yang berisi minimal dua field kunci record dari masing-masing file yang berelasi.
• Kelebihan model data relasional
a) Kecepatan dalam mengakses data
b) Data yang terkenal lebih akurat
c) Struktur datanya yang mudah dilakukan modifiaksi
d) Kemudahan dalam membangun maupun memodifikasi program pada aplikasi
• Kekurangan model data relasional
a) Pengguna harus benar-benar paham tentang hubungan antar tabel
b) Pengguna harus menguasai SQL
4) Model Relasi-Entitas
Model Relasi-Entitas atau (Entity Relationship Model) pada hakekatnya perwujudan dari model relasional dalam bentuk diagram, yaitu E-R Diagram. ERD (Entity Relationship Diagram) merupakan notasi grafis dalam pemodelan data konseptual yang mendeskripsikan hubungan antara penyimpanan dan akan membantu mengorganisasikan data dalam suatu proyek ke dalam entitas-entitas. Dengan ERD dapat menjawab data apa yang diperlukan?, bagaimana data yang satu berhubungan dengan data yang lain?
5) Model Data Berbasis Objek
Model data berbasis objek dikembangkan searah dengan perkembangan pemrograman berbasis objek. Salah satu karakteristik dari sistem berbasis objek adalah encapsulation yaitu suatu objek terpisah dari objek lain sehingga setiap objek seakan-akan berada dalam kapsulnya masing-masing. Pada setiap kapsul terdapat komponen data (attribute) dikemas bersama dengan komponen aksesnya (methods). Sebagai contoh, berikut ini disajikan data pegawai dalam format berbasis objek.
Gambar 1.1.4
BAB 2. Entity Relationship Diagram
2.1. ERD
Diagram Hubungan Entitas atau entity relationship diagram merupakan model data berupa notasi grafis dalam pemodelan data konseptual yang menggambarkan hubungan antara penyimpan. Model data sendiri merupakan sekumpulan cara, peralatan untuk mendeskripsikan data-data yang hubungannya satu sama lain, semantiknya, serta batasan konsistensi. Model data terdiri dari model hubungan entitas dan model relasional. Diagram hubungan entitas ditemukan oleh Peter Chen dalam buku Entity Relational Model-Toward a Unified of Data. Chen mencoba merumuskan dasar-dasar model dan setelah itu dikembangkan dan dimodifikai oleh Chen dan banyak pakar lainnya. Pada saat itu diagram hubungan entitas dibuat sebagai bagian dari perangkat lunak yang juga merupakan modifikasi khusus, karena tidak ada bentuk tunggal dan standar dari diagram hubungan entitas.
Diagram hubungan entitas digunakan untuk mengkonstruksikan model data konseptual, memodelkan struktur data dan hubungan antar data dan mengimplementasikan basis data secara logika maupun secara fisik dengan DBMS (Database Management system). Dengan diagram hubungan entitas ini kita dapat menguji model dengan mengabaikan proses yang harus dilakukan. Diagram hubungan entitas dapat membantu dalam menjawab persoalan tentang data yang diperlukan dan bagaimana data tersebut saling berhubungan. Contoh gambar dari Entity Relationship Diagram :
Gambar 2.1.1
Gambar 2.1.2
Symbol:
1. Persegi panjang, menyatakan himpunan entitas.
2. Oval, menyatakan atribut (atribut key digaris bawahi).
3. Belah ketupat, menyatakan himpunan relasi.
4. Garis, menyatakan penghubung antara himpunan relasi dengan himpunan entitas dan himpunan entitas dengan atributnya.
2.2. Entitas Kuat
Entitas yang mempunyai atribut kunci. Entitas ini bersifat mandiri, keberadaanya tidak bergantung pada entitas lainnya. Percepatan entitas kuat selalu memiliki karakteristik yang unik disebut identifier (sebuah atribut tunggal atau gabungan atribut-atribut yang secara unik dapat digunakan untuk membedakannya dari entitas kuat yang lain). Kebanyakan entitas dalam suatu organisasi dapat digolongkan sebagai entitas kuat (strong entity) yaitu entitas yang mandiri, yang keberadaannya tidak bergantung pada keberadaan entitas yang lainnya. Instansiasi entitas kuat selalu memiliki karakteristik yang unik (dinamakan identifier atau sering disebut sebagai atribut pengidentifikasi) yaitu, sebuah atribut tunggal atau gabungan atribut-atribut yang secara unik dapat digunakan untuk membedakannya dari entitas kuat yang lain.
2.3. Entitas Lemah
Entitas yang tidak mempunyai atribut kunci. Entitas lemah diidentifikasikan dengan menghubungkan entitas tertentu dari tipe entitas yang lain ditambah atribut dari entitas lemah. Tipe entitas lain yang dipakai untuk mengidentifikasikan suatu entitas lemah disebut identifying owner dan relasi yang menghubungkan entitas lemah dengan owner disebut identifying relationship Contoh entitas pegawai.
Gambar 2.3.1
Gambar di atas merupakan contoh dari entitas lemah dan entitas kuat. Entitas hobi merupakan entitas lemah dan entitas mahasiswa merupakan entitas kuat.
2.4. Agregasi
Dalam realitas dapat pula kita jumpai adanya relasi yang secara kronologis mensyaratkan telah adanya relasi lain. Dengan kata lain, sebuah relasi terbentuk tidak hanya dari entitas tapi juga mengandung unsur dari relasi lain. Fenomena demikian dapat diakomodasi dengan Agregasi. Menggambarkan sebuah himpunan relasi yang secara langsung menghubungkan sebuah himpunan entitas dengan sebuah himpunan relasi dalam diagram E-R, sebenarnya tidak tepat atau bahkan ada yang dengan tegas tidak memperbolehkannya.
Karena itu, sebagai jalan tengah, kita menggunakan notasi khusus untuk menunjukkan adanya agregasi semacam itu.
Gambar 2.4.1
2.5. Atribut
Entitas mempunyai elemen yang disebut atribut, dan berfungsi mendekripsikan karakter dari entitas. Atribut adalah properti atau karakteristik yang dimiliki oleh suatu entitas dimana properti atau karakteristik itu bermakna atau berarti bagi organisasi atau perusahaan, misalnya untuk pencatatan data pegawai di suatu instansi, entitas pegawai mungkin memiliki atribut-atribut nomor induk pegawai, nama, alamat, nomor telepon, gaji pokok dan lainnya. Setiap diagram hubungan entitas bisa terdapat lebih dari satu atribut. Atribut digambarkan dalam bentuk elips.Entitas memiliki himpunan atribut yang berasosiasi dengannya.
Macam-Macam Atribut
• Atribut simple atribut yang bernilai atomic, tidak dapat dipecah/ dipilah lagi.Contoh : Alamat, penerbit, tahun terbit, judul buku.
• Atribut Multivalue nilai dari suatu attribute yang mempunyai lebih dari satu (multivalue) nilai dari atrribute yang bersangkutan. Contoh : dari sebuah buku, yaitu terdapat beberapa pengarang.
• Atribut Composite Atribut composite adalah suatu atribut yang terdiri dari beberapa atribut yang lebih kecil yang mempunyai arti tertentu yang masih bisah dipecah lagi atau mempunyai sub attribute. Contoh : dari entitas nama yaitu nama depan, nama tengah, dan nama belakang
• Atribut Derivatif Atribut yang tidak harus disimpan dalam database Ex. Total. atau atribut yang dihasilkan dari atribut lain atau dari suatu relationship. Atribut ini dilambangkan dengan bentuk oval yang bergaris putus-putus.
• Derajat relasi atau kardinalitas rasio Menjelaskan jumlah maksimum hubungan antara satu entitas dengan entitas lainnya
One to One (1:1) Setiap anggota entitas A hanya boleh berhubungan dengan satu anggota entitas B, begitu pula sebaliknya.
One to many (1:M / Many) Setiap anggota entitas A dapat berhubungan dengan lebih dari satu anggota entitas B tetapi tidak sebaliknya.
Many to Many (M:M) Setiap entitas A dapat berhubungan dengan banyak entitas himpunan entitas B dan demikian pula sebaliknya.
Simbol-simbol untuk membuat diagram ERD:
Gambar 2.5.1
Contoh Kasus 1: Pada saat mendaftar menjadi anggota perpustakaan Fakultas, dicatatlah nama, nomor mahasiswa dan alamat mahasiswa. Setelah itu mereka baru bisa meminjam buku di perpustakaan. Buku-buku yang dimiliki perpustakaan banyak sekali jumlahnya. Tiap buku memiliki data nomor buku, judul, pengarang, penerbit, tahun terbit. Satu buku bisa ditulis oleh beberapa pengarang. Tentukan entitas, atribut dan relasi dari deskripsi di atas, dengan menggambar ERDnya.
Jawab: Entitas : Mahasiswa, KAP (Kartu Anggota Perpustakaan), Buku.
Atribut : Nama, no.mahasiswa, Alamat mahasiswa, No.buku, Judul, Pengarang, Penerbit dan tahun terbit.
Relasi : Daftar dan Pinjam
Gambar ERD dalam peminjaman buku di perpustakaan:
Gambar 2.5.2
• MODEL ENTITY – RELATIONSHIP
Model Entity Relationship : Suatu penyajian data dengan menggunakan Entity dan Relationship Entity :
Objek secara fisik : Buku, Perpustakaan, Mahasiswa
Objek secara konsep : Meminjam
Relationship :
Gambar 2.5.3
Atribut :
Atribut Multivalue
Gambar 2.5.4
Gambar 2.5.5
Derajat dari Relationship :
Trenary degree (Derajat Tiga)
Gambar 2.5.6
Cardinality Ratio Constraint
M : N
Gambar 2.5.7
Participation Constraint
Partial Participation
Gambar 2.5.8
Diagram ERD
Gambar 2.5.9
Contoh Kasus 2 :
Seperti soal nomor 1, namun ada beberapa tambahan penjelasan seperti berikut :
Mahasiswa kadang-kadang terlambat mengembalikan buku, sehingga dikenakan denda. Besarnya denda adalah Rp 500,- per hari keterlambatan. Mahasiswa dianggap terlambat jika mengembalikan buku lebih lama dari 1 minggu. Gambarkan ERDnya:
Gambar 2.5.10
2.6. Hubungan Relasi
Relasi adalah hubungan antara suatu himpunan dengan himpunan entitas yang lainnya. Pada penggambaran diagram hubungan entitas, relasi adalah perekat yang menghubungkan suatu entitas dengan entitas lainnya. Relasi merupakan hubungan yang berarti antara suattu entitas dengan entitas lainnya. Frasa ini berimplikasi bahwa relasi mengijinkan untuk menjawab pertanyaan-pertanyaan yang berkaitan dengan hubungan suatu entits dengan lainya. Hubungan dibedakan antar bentuk hubungan antar entitas dengan isinya masing-masing. Misalnya kasus hubungan antara entitas pegawai dan entitas bagian adalah jam kerja, sedangkan isi hubungannya dapat berupa total jam kerja, gaji lembur.
Relasi digambarkan dalam bentuk intan. Pada model data relasi hubungan antar data dihubungkan dengan kunci relasi. Tipe hubungan di antara beberapa buah tipe entitas adalah kumpulan dari relasi di antara entitas-entitas dari tipe entitas tersebut. Karakteristik dari Relasi Relasi mempunyai karakteristik terdiri dari kumpulan tuple-tuple, urutan dari tuple-tuple merepresenrasikan data pada tingkat abstrak logis dan urutam data dianggap penting. Batas Keikutsertaan ( Participation onstrain) Batas keikutsertaan dari relasi terdiri dari total, parsial, satu ke satu, satu ke banyak atau banyak ke satu, dan banyak ke banyak. Batas total menunjukkan pada semua elemen, misalnya semua karyawan harus bekerja pada suatu departemen.
Batas parsial menunjukkan pada suatu entitas tertentu hanya berhubungan dengan satu entitas yang lain. Batas satu ke satu menunjukkan pada atribut kunci pada derajat relasi dapat ditempatkan pada salah satu entitas. Batas satu ke banyak menunjukkan attribut kunci pada derajat relasi ini hanya dapat dimasukan sebagai atribut dari tipe entitas pada sisi N dan batas banyak ke banyak menunjukkan sejumlah entitas berhubungan dengan sejumlah entitas B. Atribut ini harus tetap di nyatakan sebagai atribut relasi dan tidak dapat digabungkan pada salah satu entitas yang terlibat.
BAB 3. DATA FLOW DIAGRAM
3.1. Konsep Perancangan Terstruktur
Pendekatan perancangan terstruktur dimulai dari awal 1970. Pendekatan terstruktur dilengkapi dengan alat-alat (tools) dan teknik-teknik (techniques) yang dibutuhkan dalam pengembangan sistem, sehingga hasil dari akhir sistem yang dikembangkan akan diperoleh sistem yang strukturnya didefinisikan dengan baik dan jelas.
Melalui pendekatan terstruktur, permasalahan yang komplek di organisasi dapat dipecahkan dan hasil dari sistem akam mudah untuk dipelihara, fleksibel, lebih memuaskan pemakainya, mempunyai dokumentasi yang baik, tepat waktu, sesuai dengan anggaran biaya pengembangan, dapat meningkatkan produktivitas dan kualitasnya akan lebih baik (bebas kesalahan).
3.2. Data Flow Diagram (DFD)
Data Flow Diagram (DFD) 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.
DFD ini adalah salah satu alat pembuatan model yang sering digunakan, khususnya bila fungsi-fungsi sistem merupakan bagian yang lebih penting dan kompleks dari pada data yang dimanipulasi oleh sistem. Dengan kata lain, DFD adalah alat pembuatan model yang memberikan penekanan hanya pada fungsi sistem.
DFD ini merupakan alat perancangan sistem yang berorientasi pada alur data dengan konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan sistem yang mudah dikomunikasikan oleh profesional sistem kepada pemakai maupun pembuat program.
Fungsi DFD Fungsi dari Data Flow Diagram adalah :
• Data Flow Diagram (DFD) adalah alat pembuatan model yang memungkinkan profesional sistem untuk menggambarkan sistem sebagai suatu jaringan proses fungsional yang dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi.
• DFD ini adalah salah satu alat pembuatan model yang sering digunakan, khususnya bila fungsi-fungsi sistem merupakan bagian yang lebih penting dan kompleks dari pada data yang dimanipulasi oleh sistem. Dengan kata lain, DFD adalah alat pembuatan model yang memberikan penekanan hanya pada fungsi sistem.
• DFD ini merupakan alat perancangan sistem yang berorientasi pada alur data dengan konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan sistem yang mudah dikomunikasikan oleh profesional sistem kepada pemakai maupun pembuat program.
3.3. Komponen Data Flow Diagram
DFD merupakan alat bantu dalam menggambarkan atau menjelaskan proses kerja suatu sistem.
Gambar 3.3.1
1. User / Terminator: Kesatuan diluar sistem (external entity) yang memberikan input ke sistem atau menerima output dari sistem berupa orang, organisasi, atau sistem lain.
2. Process: Aktivitas yang mengolah input menjadi output.
3. Data Flow: Aliran data pada sistem (antar proses, antara terminator & proses, serta antara proses & data store).
4. Data Store: Penyimpanan data pada database, biasanya berupa tabel.
• Komponen Terminator / Entitas Luar Terminator mewakili entitas eksternal yang berkomunikasi dengan sistem yang sedang dikembangkan. Biasanya terminator dikenal dengan nama entitas luar (external entity).
Terdapat dua jenis terminator:
1. Terminator Sumber (source) : merupakan terminator yang menjadi sumber.
2. Terminator Tujuan (sink) : merupakan terminator yang menjadi tujuan data / informasi sistem.
Gambar 3.3.2
Terminator dapat berupa orang, sekelompok orang, organisasi, departemen di dalam organisasi, atau perusahaan yang sama tetapi di luar kendali sistem yang sedang dibuat modelnya.
Terminator dapat jua berupa departemen, divisi atau sistem di luar sistem yang berkomunikasi dengan sistem yang sedang dikembangkan.
Komponen terminator ini perlu diberi nama sesuai dengan dunia luar yang berkomunikasi dengan sistem yang sedang dibuat modelnya, dan biasanya menggunakan kata benda, misalnya Bagian Penjualan, Dosen, Mahasiswa.
Ada tiga hal penting yang harus diingat tentang terminator :
1. Terminator merupakan bagian/lingkungan luar sistem. Alur data yang menghubungkan terminator dengan berbagai proses sistem, menunjukkan hubngan sistem dengan dunia luar.
2. Profesional sistem tidak dapat mengubah isi atau cara kerja organisasi, atau prosedur yang berkaitan dengan terminator.
3. Hubungan yang ada antar terminator yang satu dengan yang lain tidak digambarkanpada DFD.
• Komponen Proses Komponen proses menggambarkan bagian dari sistem yang mentransformasikan input menjadi output.
Proses diberi nama untuk menjelaskan proses/kegiatan apa yang sedang/akan dilaksanakan. Pemberian nama proses dilakukan dengan menggunakan kata kerja transitif (kata kerja yang membutuhkan obyek), seperti Menghitung Gaji, Mencetak KRS, Menghitung Jumlah SKS.
Ada empat kemungkinan yang dapat terjadi dalam proses sehubungan dengan input dan output :
Gambar 3.3.3
Ada beberapa hal yang perlu diperhatikan tentang proses :
- Proses harus memiliki input dan output.
- Proses dapat dihubungkan dengan komponen terminator, data store atau proses melalui alur data.
- Sistem/bagian/divisi/departemen yang sedang dianalisis oleh profesional sistem digambarkan dengan komponen proses.
Berikut ini merupakan suatu contoh proses yang salah :
Gambar 3.3.4
Umumnya kesalahan proses di DFD adalah :
1. Proses mempunyai input tetapi tidak menghasilkan output. Kesalahan ini disebut dengan black hole (lubang hitam), karena data masuk ke dalam proses dan lenyap tidak berbekas seperti dimasukkan ke dalam lubang hitam (lihat proses 1).
2. Proses menghasilkan output tetapi tidak pernah menerima input. Kesalahan ini disebut dengan miracle (ajaib), karena ajaib dihasilkan output tanpa pernah menerima input (lihat Gambar 3.3.4 proses 2).
• Komponen Data Store Komponen ini digunakan untuk membuat model sekumpulan paket data dan diberi nama dengan kata benda jamak, misalnya Mahasiswa.
Data store ini biasanya berkaitan dengan penyimpananpenyimpanan, seperti file atau database yang berkaitan dengan penyimpanan secara komputerisasi, misalnya file disket, file harddisk, file pita magnetik. Data store juga berkaitan dengan penyimpanan secara manual seperti buku alamat, file folder, dan agenda.
Suatu data store dihubungkan dengan alur data hanya pada komponen proses, tidak dengan komponen DFD lainnya. Alur data yang menghubungkan data store dengan suatu proses mempunyai pengertian sebagai berikut :
- Alur data dari data store yang berarti sebagai pembacaan atau pengaksesan satu paket tunggal data, lebih dari satu paket data, sebagian dari satu paket tunggal data, atau sebagian dari lebih dari satu paket data untuk suatu proses (lihat Gambar 3.3.5 (a)).
- Alur data ke data store yang berarti sebagai pengupdatean data, seperti menambah satu paket data baru atau lebih, menghapus satu paket atau lebih, atau mengubah/memodifikasi satu paket data atau lebih (lihat Gambar 3.3.5 (b)).
Pada pengertian pertama jelaslah bahwa data store tidak berubah, jika suatu paket data/informasi berpindah dari data store ke suatu proses. Sebaliknya pada pengertian kedua data store berubah sebagai hasil alur yang memasuki data store. Dengan kata lain, proses alur data bertanggung jawab terhadap perubahan yang terjadi pada data store.
Gambar 3.3.5
• Komponen Data Flow / Alur Data
Suatu data flow / alur data digambarkan dengan anak panah, yang menunjukkan arah menuju ke dan keluar dari suatu proses. Alur data ini digunakan untuk menerangkan perpindahan data atau paket data/informasi dari satu bagian sistem ke bagian lainnya.
Selain menunjukkan arah, alur data pada model yang dibuat oleh profesional sistem dapat merepresentasikan bit, karakter, pesan, formulir, bilangan real, dan macam-macam informasi yang berkaitan dengan komputer. Alur data juga dapat merepresentasikan data/informasi yang tidak berkaitan dengan komputer.
Alur data perlu diberi nama sesuai dengan data/informasi yang dimaksud, biasanya pemberian nama pada alur data dilakukan dengan menggunakan kata benda, contohnya Laporan Penjualan.
Ada empat konsep yang perlu diperhatikan dalam penggambaran alur data, yaitu :
• Konsep Paket Data (Packets of Data)
Apabila dua data atau lebih mengalir dari suatu sumber yang sama menuju ke tujuan yang sama dan mempunyai hubungan, dan harus dianggap sebagai satu alur data tunggal, karena data itu mengalir bersama-sama sebagai satu paket.
Gambar 3.3.6
• Konsep Alur Data Menyebar (Diverging Data Flow)
Alur data menyebar menunjukkan sejumlah tembusan paket data yang yang berasal dari sumber yang sama menuju ke tujuan yang berbeda, atau paket data yang kompleks dibagi menjadi beberapa elemen data yang dikirim ke tujuan yang berbeda, atau alur data ini membawa paket data yang memiliki nilai yang berbeda yang akan dikirim ke tujuan yang berbeda.
Gambar 3.3.7
• Konsep Alur Data Mengumpul (Converging Data Flow)
Beberapa alur data yang berbeda sumber bergabung bersama-sama menuju ke tujuan uang sama.
Gambar 3.3.8
• Konsep Sumber atau Tujuan Alur Data Semua alur data harus minimal mengandung satu proses. Maksud kalimat ini adalah :
- Suatu alur data dihasilkan dari suati proses dan menuju ke suatu data store dan/atau terminator (lihat Gambar 3.3.9 (a)).
- Sutu alur data dihasilkan dari suatu data store dan/atau terminator dan menuju ke suatu proses (lihat Gambar 3.3.9 (b)).
- Suatu alur data dihasilkan dari suatu proses dan menuju ke suatu proses (lihat Gambar 3.3.9 (c)).
Gambar 3.3.9
3.4. Bentuk Data Flow Diagram
Terdapat dua bentuk DFD, yaitu Diagram Alur Data Fisik, dan Diagram Alur data Logika. Diagram alur data fisik lebih menekankan pada bagaimana proses dari sistem diterapkan, sedangkan diagram alur data logika lebih menekankan proses-proses apa yang terdapat di sistem.
• Diagram Alur Data Fisik (DADF) DADF lebih tepat digunakan untuk menggambarkan sistem yang ada (sistem yang lama). Penekanan dari DADF adalah bagaimana proses-proses dari sistem diterapkan (dengan cara apa, oleh siapa dan dimana), termasuk proses-proses manual.
Untuk memperoleh gambaran bagaimana sistem yang ada diterapkan, DADF harus memuat :
- Proses-proses manual juga digambarkan. 2.
- Nama dari alur data harus memuat keterangan yang cukup terinci untuk menunjukkan bagaimana pemakai sistem memahami kerja sistem. 3.
- Simpanan data dapat menunjukkan simpanan non komputer. 4.
- Nama dari simpanan data harus menunjukkan tipe penerapannya apakah secara manual atau komputerisasi. Secara manual misalnya dapat menunjukkan buku catatat, meja pekerja. Sedang cara komputerisasi misalnya menunjukkan file urut, file database.
- Proses harus menunjukkan nama dari pemroses, yaitu orang, departemen, sistem komputer, atau nama program komputer yang mengakses proses tersebut.
• Diagram Alur Data Logika (DADL) DADL lebih tepat digunakan untuk menggambarkan sistem yang akan diusulkan (sistem yang baru). Untuk sistem komputerisasi, penggambaran DADL hanya menunjukkan kebutuhan proses dari sistem yang diusulkan secara logika, biasanya proses-proses yang digambarkan hanya merupakan proses-proses secara komputer saja.
Gambar 3.4.1
(a) Diagram Alur Data Logika
Gambar 3.4.2
(b) Diagram Alur Data Fisik
Gambar 3.4.1 dan Gambar 3.4.2 adalah DADF dan DADL
3.5. Syarat-syarat Pembuatan Data Flow Diagram
Syarat pembuatan DFD ini akan menolong profesional sistem untuk menghindari pembentukkan DFD yang salah atau DFD yang tidak lengkap atau tidak konsisten secara logika. Beberapa syarat pembutan DFD dapat menolong profesional sistem untuk membentuk DFD yang benar, menyenangkan untuk dilihat dan mudah dibaca oleh pemakai.
Syarat-syarat pembuatan DFD ini adalah :
- Pemberian nama untuk tiap komponen DFD.
- Pemberian nomor pada komponen proses.
- Penggambaran DFD sesering mungkin agar enak dilihat.
- Penghindaran penggambaran DFD yang rumit.
- Pemastian DFD yang dibentuk itu konsiten secara logika.
• Pemberian Nama untuk Tiap komponen DFD
Seperti yang telah dijelaskan sebelumnya, komponen terminator mewakili lingkungan luar dari sistem, tetapi mempunyai pengaruh terhadap sistem yang sedang dikembangkan ini. Maka agar pemakai mengetahui dengan lingkungan mana saja sistem mereka berhubungan, komponen terminator ini harus diberi nama sesuai dengan lingkungan luar yang mempengaruhi sistem ini. Biasanya komponen terminator diberi nama dengan kata benda. Selanjutnya adalah komponen proses.
Komponen proses ini mewakili fungsi sistem yang akan dilaksanakan atau menunjukkan bagaimana fungsi sistem dilaksanakan oleh seseorang, sekelompok orang atau mesin. Maka sangatlah jelas bahwa komponen ini perlu diberi nama yang tepat, agar siapa yang membaca DFD khususnya pemakai akan merasa yakin bahwa DFD yang dibentuk ini adalah model yang akurat.
Pemberian nama pada komponen proses lebih baik menunjukkan aturan-aturan yang akan dilaksanakan oleh seseorang dibandingkan dengan memberikan nama atau identitas orang yang akan melaksanakannya. Ada dua alasan mengapa bukan nama atau identitas orang (yang melaksanakan fungsi sistem) yang digunakan sebagai nama proses, yaitu :
- Orang tersebut mungkin diganti oleh orang lain saat mendatang, sehingga bila tiap kali ada pergantian orang yang melaksanakan fungsi tersebut, maka sistem yang dibentuk harus diubah lagi.
- Orang tersebut mungkin tidak melaksanakan satu fungsi sistem saja, melainkan beberapa fungsi sistem yang berbeda. Daripada menggambarkan beberapa proses dengan nama yang sama tetapi artinya berbeda, lebih baik tunjukkan dengan tugas/fungsi sistem yang sebenarnya akan dilaksanakan.
Karena nama untuk komponen proses lebih baik menunjukkan tugas/fungsi sistem yang akan dilaksanakan, maka lebih baik pemberian nama ini menggunakan kata kerja transitif.
Pemberian nama untuk komponen data store menggunakan kata benda, karena data store menunjukkan data apa yang disimpan untuk kebutuhan sistem dalam melaksanakan tugasnya. Jika sistem sewaktu-waktu membutuhkan data tersebut untuk melaksanakan tugasnya, maka data tersebut tetap ada, karena sistem menyimpannya.
Begitu pula untuk komponen alur data, namanya lebih baik diberikan dengan menggunakan kata benda. Karena alur data ini menunjukkan data dan infiormasi yang dibutuhkan dan yang dikeluarkan oleh sistem dalam pelaksanaan tugasnya.
• Pemberian Nomor pada Komponen Proses
Biasanya profesional sistem memberikan nomor dengan bilangan terurut pada komponen proses sebagai referensi. Tidak jadi masalah bagaimana nomor-nomor proses ini diberikan. Nomor proses dapat diberikan dari kiri ke kanan, atau dari atas ke bawah, atau dapat pula dilakukan dengan pola-pola tertentu selama pemberian nomor ini tetap konsisten pada nomor yang dipergunakan.
Gambar 3.5.1
Nomor-nomor proses yang diberikan terhadap komponen proses ini tidak dimaksudkan bahwa proses tersebut dilaksanakan secara berurutan. Pemberian nomor ini dimaksudkan agar pembacaan suatu proses dalam suatu diskusi akan lebih mudah dengan hanya menyebutkan prosesnya saja jika dibandingkan dengan menyebutkan nama prosesnya, khususnya jika nama prosesnya panjang dan sulit. Maksud pemberian nomor pada proses yang lebih penting lagi adalah untuk menunjukkan referensi terhadap skema penomoran secara hirarki pada levelisasi DFD. Dengan kata lain, nomor proses ini merupakan dasar pemberian nomor pada levelilasi DFD (lihat gambar 3.5.1).
• Penggambaran DFD sesering mungkin Penggambaran DFD dapat dilakukan berkali-kali sampai secara teknik DFD itu benar, dapat diterima oleh pemakai, dan sudah cukup rapih sehingga profesional sistem tidak merasa malu untuk menunjukkan DFD itu kepada atasannya dan pemakai.
Dengan kata lain, penggambaran DFD ini dilakukan sampai terbentuk DFD yang enak dilihat, dan mudah dibaca oleh pemakai dan profesional sistem lainnya. Keindahan penggambaran DFD tergantung pada standar-standar yang diminta oleh organisasi tempat profesional sistem itu bekerja dan perangkat lunak yang dipakai oleh profesional sistem dalam membuat DFD.
Penggambaran yang enak untuk dilihat dapat dilakukan dengan memperhatikan hal-hal berikut ini :
Ukuran dan bentuk proses Beberapa pemakai kadang-kadang merasa bingung bila ukuran proses satu berbeda dengan proses yang lain. Mereka akan mengira bahwa proses dengan ukuran yang lebih besar akan diduga lebih penting dari proses yang lebih kecil. Hal ini sebenarnya hanya karena nama proses itu lebih panjang dibandingkan dengan proses yang lain. Jadi, sebaiknya proses yang digambarkan memiliki ukuran dan bentuk yang sama.
Alur data melingkar dan alur data lurus Alur data dapat digambarkan dengan melingkar atau hanya garis lurus. Mana yang lebih enak dipandang tergantung siapa yang akan melihat DFD tersebut.
Gambar 3.5.2
DFD dengan gambar tangan dan gambar menggunakan mesin. DFD dapat digambarkan secara manual atau dengan menggunakan bantuan mesin, tergantung pilihan pemakai atau profesional sistem.
• Penghindaran Penggambaran DFD yang rumit Tujuan DFD adalah untuk membuat model fungsi yang harus dilaksanakan oleh suatu sistem dan interaksi antar fungsi. Tujuan lainnya adalah agar model yang dibuat itu mudah dibaca dan dimengerti tidak hanya oleh profesional sistem yang membuat DFD, tetapi juga oleh pemakai yang berpengalaman dengan subyek yang terjadi. Hal ini berarti DFD harus mudah dimengerti, dibaca, dan menyenangkan untuk dilihat.
Pada banyak masalah, DFD yang dibuat tidak memiliki terlalu banyak proses (maksimal enam proses) dengan data store, alur data, dan terminator yang berkaitan dengan proses tersebut dalam satu diagram.
Bila terlalu banyak proses, terminator, data store, dan alur data digambarkan dalam satu DFD, maka ada kemungkinan terjadi banyak persilangan alur data dalam DFD tersebut. Persilangan alur data ini menyebabkan pemakai akan sulit membaca dan mengerti DFD yang terbentu. Jadi semakin sedikit adanya persilangan data pada DFD, maka makin baik DFD yang dibentuk oleh profesional sistem.
Persilangan alur data ini dapat dihindari dengan menggambarkan DFD secara bertingkat-tingkat (levelisasi DFD), atau dengan menggunakan pemakaian duplikat terhadap komponen DFD.
Komponen DFD yang dapat menggunakan duplikat hanya komponen store dan terminator. Pemberian duplikat ini juga tidak dapat diberikan sesuka profesional sistem yang membuat DFD, tetapi makin sedikit pemakaian duplikat, makin baik DFD yang terbentuk. Pemberian duplikat terhadap data store dilakukan dengan memberikan simbol garis lurus (ξ) atau asterik (*), sedangkan untuk terminator menggunakan simbol garis miring (/) atau asterik (*). Banyaknya pemberian simbol duplikat pada duplikat yang digunakan tergantung banyaknya duplikat yang digunakan.
Gambar 3.5.3
• Penggambaran DFD yang Konsisten Penggambaran DFD harus konsisten terhadap kelompok DFD lainnya. Profesional sistem menggambarkan DFD berdasarkan tingkatan DFD dengan tujuan agar DFD yang dibuatnya itu mudah dibaca dan dimengerti oleh pemakai sistem. Hal ini sesuai dengan salah satu tujuan atau syarat membuat DFD.
3.6. Penggambaran DFD
Tidak ada aturan baku untuk menggambarkan DFD. Tapi dari berbagai referensi yang ada, secara garis besar langkah untuk membuat DFD adalah :
1. Identifikasi terlebih dahulu semua entitas luar yang terlibat di sistem.
2. Identifikasi semua input dan output yang terlibat dengan entitas luar.
3. Buat Diagram Level Satu
Didalam DFD terdapat 3 level, yaitu :
1. Diagram Konteks : menggambarkan satu lingkaran besar yang dapat mewakili seluruh proses yang terdapat di dalam suatu sistem. Merupakan tingkatan tertinggi dalam DFD dan biasanya diberi nomor 0 (nol). Semua entitas eksternal yang ditunjukkan pada diagram konteks berikut aliran-aliran data utama menuju dan dari sistem. Diagram ini sama sekali tidak memuat penyimpanan data dan tampak sederhana untuk diciptakan. Diagram ini adalah diagram level tertinggi dari DFD yang menggambarkan hubungan sistem dengan lingkungan luarnya. Caranya :
- Tentukan nama sistemnya.
- Tentukan batasan sistemnya.
- Tentukan terminator apa saja yang ada dalam sistem.
- Tentukan apa yang diterima/diberikan terminator dari/ke sistem.
- Gambarkan diagram konteks.
2. Diagram Nol (diagram level-1) :merupakan satu lingkaran besar yang mewakili lingkaran-lingkaran kecil yang ada di dalamnya. Merupakanpemecahan dari diagram Konteks ke diagram Nol. di dalam diagram ini memuat penyimpanan data. Diagram ini adalah dekomposisi dari diagram konteks. Caranya :
- Tentukan proses utama yang ada pada sistem.
- Tentukan apa yang diberikan/diterima masing-masing proses ke/dari sistem sambil memperhatikan konsep keseimbangan (alur data yang keluar/masuk dari suatu level harus sama dengan alur data yang masuk/keluar pada level berikutnya).
- Apabila diperlukan, munculkan data store (master) sebagai sumber maupun tujuan alur data.
- Gambarkan diagram level zero. o Hindari perpotongan arus data. o Beri nomor pada proses utama (nomor tidak menunjukkan urutan proses).
3. Diagram Rinci : merupakan diagram yang menguraikan proses apa yang ada dalam diagram Nol. Diagram ini merupakan dekomposisi dari diagram level zero. Caranya :
- Tentukan proses yang lebih kecil (sub-proses) dari proses utama yang ada di level zero.
- Tentukan apa yang diberikan/diterima masing-masing subproses ke/dari sistem dan perhatikan konsep keseimbangan.
- Apabila diperlukan, munculkan data store (transaksi) sebagai sumber maupun tujuan alur data.
- Gambarkan DFD level Satu o Hindari perpotongan arus data. o Beri nomor pada masing-masing sub-proses yang menunjukkan dekomposisi dari proses sebelumnya. Contoh : 1.1, 1.2, 2.1 - DFD Level Dua, Tiga... Diagram ini merupakan dekomposisi dari level sebelumnya. Proses dekomposisi dilakukan sampai dengan proses siap dituangkan ke dalam program. Aturan yang digunakan sama dengan level satu.
Gambar 3.6.1
BAB 4. SPESIFIKASI PROSES
Spesifikasi Proses menggambarkan kejadian di dalam setiap bubble pada level terbawah pada data flow diagram. Spesifikasi proses mendefinisikan kegiatan yang harus dilakukan untuk mengubah input menjadi output (Edward Yourdon, Modern Structured Analysis, hal. 203). Sepsifikasi proses digunakan untuk mendeskripsikan proses yang terjadi pada level yang paling dasar dalam DFD. Model ini berfungsi mendeksripsikan apa yang dilakukan ketika masukan ditransformasi menjadi keluaran.
Ada berbagai macam tools yang dapat kita gunakan untuk menghasilkan suatu spesifikasi proses: tabel keputusan, Bahasa Inggris terstruktur, pre/post condition, flowcharts, diagram Nassishneiderman, dan lain sebagainya. Sedangkan kebanyakan analisis sistem mengarah ke Bahasa Inggris terstruktur, anda harus ingat bahwa setiap metode dapat digunakan, selama hal tersebut memuaskan dua keadaan penting:
1. Spesifikasi proses harus ditampilkan dalam suatu bentuk/form yang dapat diverifikasi oleh user dan sistem analis. Kondisi ini tepat untuk alasan ini, dimana kita mengurangi paparan Bahasa Inggris sebagai sebuah alat spesifikasi: hal ini dikenal sebagai ambigu, khususnya apabila menggambarkan tindakan (keputusan) alternatif dan tindakan berulang (loops). Secara alami, hal tersebut juga cenderung menyebabkan kebingungan yang sangat ketika mengekspresikan bagian-bagian kondisi Boolean (misalkan kombinasi dari operator Boolean AND, OR dan NOT).
2. Spesifikasi proses harus ditampilkan dalam suatu bentuk/form yang dapat mengkomunikasikan secara efektif berbagagai keterlibatan berbagai latar belakang pendengar. Sedangkan hal tersebut akan menjadi tipe dari analis sistem yang menuliskan spesifikasi proses, hal tersaebut biasanya menjadi bermacam-mcam pendengar dari para pengguna, manager, auditor, personil quality assurance, dan lainnya yang membaca spesifikasi proses. Suatu proses spesifikasi diharapkan dapat ditampilkan dalam perhitungan yang dapat diprediksi, atau dalam pascal, atau dalam pendekatan format diagram seperti software use-it; tetapi jika komunitas user menolak untuk melihat pada beberapa spesifikasi, mereka adalah tidak berharga.
BAB 5. DATA DICTIONARY
Data Dictionary atau Kamus data adalah suatu daftar data elemen yang terorganisir dengan definisi yang tetap dan sesuai dengan sistem, sehingga user dan analis sistem mempunyai pengertian yang sama tentang input, output, dan komponen data strore.
Menurut Budi Sutedjo Dharma Oetomo (2002 : 118) Kamus data ikut berperan dalam perancangan dan pembangunan sistem informasi karena peralatan ini berfungsi untuk :
1. Menjelaskan arti aliran data dan penyimpanan dalam penggambaran dalam data flow diagram.
2. Mendeskripsikan komposisi paket data yang bergerak melalui aliran, misalnya data alamat diurai menjadi nama jalan, nomor, kota, negara dan kode pos.
3. Menjelaskan spesifikasi nilai dan satuan yang relevan terhadap data yang mengalir dalam sistem tersebut Roger S. Pressman, Ph.D dalam bukunya Rekayasa Perangkat lunak menuliskan bahwa kamus data merupakan suatu daftar yang terorganisasi dari elemen data yang berhubungan dengan sistem, dengan definisi yang tegar dan teliti sehingga pemakai analisis sistem akan memiliki pemahaman yang umum mengenai input, output, komponen pemyimpanan, dan bahkan kalkulasi intermediate.
Dan informasi yang terdapat di dalam kamus data menurut Roger S. Pressman, Ph.D yaitu :
1. Name yaitu nama sebenarnya dari data atau item kontrol, penyimpanan data, atau entitas eksternal
2. Alias yaitu nama lain yang digunakan untuk entri pertama.
3. Where-used/how-used yaitu suatu daftar dari proses yang menggunakan data atau item kontrol dan bagaimana dia digunakan.
4. Content description yaitu suatu notasi untuk merepresentasikan isi.
5. Supplementary information yaitu informasi lain mengenai tipe data, harga preset (bila diketahui), barasan, dll.
BAB 6. MASA DEPAN PEMODELAN DATA
6.1. PEMODELAN DATA
Mesin yang dihasilkan
Melihat data yang dihasilkan mesin membuat anda bertanya-tanya tentang Pemodelan Data semacam itu. Siapa yang tahu ? Sebenarnya, seluruh Big Data disebabkan oleh data ‘dihasilkan mesin’ yang datang dalam jumlah besar. Tak terhentikan.
Gambar 6.1.1
Kita semua tahu bahwa ‘mesin dihasilkan’ sebenarnya bukan deskripsi yang tepat tentang apa yang sedang terjadi. Ya, “benda” (Komputer tertanam di tepi internet) mentransmisikan data, tetapi itu bukan hal baru. Untuk sebagian besar karir Panjang saya, hal yang sama berlaku untuk factor dan banyak hal lainnya. Dan hal-hal yang dihasilkan IT dengan cermat istilah yang digunakan adalah “modeled”. Ini telah terjadi selama beberapa tahun. Para insinyur perangkat lunak bekerja Bersama dengan Pemodelan Data dan Bersama-sama mereka membuat model faktur yang sangat bagus. Pada saat yang sama, Ilmuwan Informasi (jangan panggil mereka pustakawan), membantu para insinyur dan ilmuwan di organisasi pabrikan, kimia, farmasi, dan public untuk mengembangkan dan memelihara kosa kata bisnis yang solid dan tepat (ontology dan sejenisnya). Apa yang kemudian terjadi adalah bahwa insinyur perangkat lunak, yang bekerja dengan jadwal yang ketat, mengurangi dukungan dari Pemodelan Data. Dan para ilmuwan informasi mendapat lebih banyak dan lebih banyak bantuan mesin dari penggalian teks kategori, entitas, tema dan sebagainya.
Masukkan Data Para ilmuwan menghadapi tsunami data yang dihasilkan. Karena banyak data yang mereka terima “tidak dirancang di sini”, mereka kesulitan mencari tahu, apa yang mereka pegang. Data Para ilmuwan diikuti oleh pengabaian baru bantuan mesin yang disebut misalnya “ Data Discovery”, yang juga mencakup Data Profiling dan Domain Discovery. Jadi, para ilmuwan Data, antara lain, juga membangun model data – meskipun model data dalam statistic tidak cukup sama dengan model data dalam buku teks oleh Chris Date.
Siapa Aktor di Pemodelan Data ?
Saat ini, setidaknya ada kategori orang yang melakukan ini, apa yang 30 tahun lalu hanya dilakukan oleh Pemodel Data :
• Pemodelan Data
• Pengembangan Perangkat Lunak dalam Sistem TI atau Sistem Tertanam
• Beberapa dengan latar belakang ilmu Komputer dan
• Lain dengan gelar Teknik atau Manajemen Bisnis.
• Ilmuwan Informasi
• Ilmuwan Data
Sebagian besar dari orang-orang baik ini memiliki gelar akademik. Baik Ilmu Informasi dan Ilmu Data memiliki penawaran gelar sarjana atau Magister yang baik masing-masing selama 2-3 tahun dan 1-2 tahun. Pemodelan dalam beberapa bentuk atau bentuk adalah bagian yang baik dari Pendidikan. Ketika datang ke Pemodel Data, tidak ada Ilmu Pemodelan Data dengan gelar sarjana atau master sendiri.
Banyak Pemodelan Data memiliki latar belakang ilmu komputer, dan dalam kurikulum itu Pemodelan Data biasanya merupakan program satu semester. Oleh karena itu, sebagian besar Pemodel Data mengandalkan Pendidikan tambahan :
• Vendor basis data dan,
• Penyedia independent seperti, paling tidak, DATAVERSITY ®! Para insinyur, yang tahu bagaimana memprogram (Kebanyakan dari mereka telah terpapar padanya) mungkin tidak memiliki pelatihan yang layak disebutkan dalam Pemodelan Data. Tambahkan bahwa mereka juga melihat sensor (atau apapun) data dari dalam toples teknis.
Apa yang bisa kita lakukan untuk membantu mereka yang membutuhkan keterampilan Pemodelan Data ?
Apa Set Keterampilan ? Jika kita ingin memperbaikin situasi ini, dan kita harus melakukannya,kita perlu memahami serangkaian keterampilan yang diperlukan di berbagai perspektif berbeda tentang manajemen data informasi. Secara khusus, akan menarik untuk melihat keterampilan, yang dibagi di antara set :
Gambar 6.1.2
Akibatnya, saya melakukan beberapa analisis teks sederhana berdasarkan Wikipedia. Saya menggunakan fasilitas demo online dari vendor (Lexalytics), tempat Anda dapat menempelkan URL dan Anda akan mendapatkan beberapa analitik teks kembali. Saya tertarik dengan tema yang terkandung dalam tiga artikel Wikipedia tentang Pemodelan Data, Ilmu Data, dan Ilmu Informasi. Saya menyalin / menempelkannya ke lembar Excel dan menerapkan beberapa tea saya sendiri, yang menurut pengalaman saya seharusnya ada disana).
Saya menambahkan set keempat “sains” tema yang disebut “Future Modeling” mengambil dari 3 lainnya dan menambahkan apa yang saya piker sangat penting untuk Pemodelan Data dimasa depan ( yang dimulai hari ini). Saya kemudian memuat daftar tema ke dalam Neo4j Graph Database, dan inilah yang saya dapat sebagai balasannya :
Gambar 6.1.3
Di atas hanya untuk memberi Anda gambaran tentang ukuran grafik – jangan melihat kaca yang Anda cari! Namun, Anda dapat melihat (Ke bagian luar grafik) bahwa beberapa tema bersifat local untuk “sains”. Itu yang diharapkan. Data Para ilmuwan adalah ahli matematika dan statistic, dan ilmuwan informasi adalah ahli dalam istilah, misalnya.
Tapi apa yang dibagikan di antara mereka ?
Keterampilan Bersama
Gambar 6.1.4
Di sini Anda dapat melihat bahwa beberapa keterampilan sangat umum (seperti “komputasi”) dan lainnya lebih spesifik. Saya sebenarnya menambahkan beberapa, yang saya yakin sudah hari ini adalah bagian dari kenyataan : Manajemen informasi, pemrosesan Bahasa alami dan penemuan data. Yang menarik untuk dilihat adalah bahwa Pemodelan Data dan ilmu informasi sebenarnya berbagi 11 tema. Para ilmuwan informasi, ingatlah, memiliki pelatihan akademik hingga 5 tahun.
Saya percaya bahwa Pemodelan Data harus berpegangan pada pagar dan berlayar bersama, karena para ilmuwan informasi memiliki beberapa keterampilan yang kuat untuk ditawarkan. Mereka mungkin bukan ahli dalam bentuk normal ke-5, mungkin itu bukan masalah terpanas hari ini? Sangat menarik untuk melihat bahwa Ilmu Informasi dan Ilmu Data memiliki banyak tumpeng tindih di sisi otomasi.
Tumpeng tindih antara Pemodelan Data dan Ilmuwan Data pada keterampilan Pemodelan Data inti, yang juga harus membuat kita berpikir. Bagaimana dengan masa depan langsung ? Pemodelan Data dari Sekarang Aktif Jika saya memilih sub-grafik, di mana “ilmu Pemodelan Data” diganti oleh “ilmu Pemodelan Masa Depan”, grafiknya tampak seperti ini:
Gambar 6.1.5
(Set lengkap keterampilan “Future Modeling” dapat dilihat di akhir posting ini.) Sekali lagi, Anda tidak diharapkan untuk membaca semua detail, tetapi tumpang tindih antara “Future Modeling” dan “Ilmu Informasi” telah meningkat. Contoh terbaik adalah peluang Grafik Pengetahuan untuk digunakan untuk tujuan integrase data. Pemodelan Data Grafik juga merupakan contoh yang baik dari keterampilan yang umumnya bermanfaat.
Apakah kita melihat perlombaan dimulai antara Pemodelan Data dan Ilmuwan Informasi, di mana wanita dan pria terbaik menang? Aku piker begitu. Pada skala yang lebih kecil, jumlah kesamaan kolegial antara Pemodelan Data masa depan dan ilmuwan data juga meningkat dalam jumlah dan kompleksitas; lihat misalnya visualisasi dan pengetahuan tentang cara memodelkan analitik prediktif. Untuk membuatnya lebih mudah, saya telah mengekstrak sub-grafik dari tema Bersama (keterampilan) di antara ketiganya, dengan melihat ke depan :
Gambar 6.1.6
Beberapa hal dapat disimpulkan dari grafik di atas :
• Pemodelan Data harus bekerja dari perspektif kontinuitas bisnis, memastikan bahwa basis data dan konten aplikasi diatur dan demikian
• Informasi Para ilmuwan harus bekerja dari perspektif kualitas bisnis, dan temuan mereka (ontology, kosakata dan sebagainya) harus menemukan jalan mereka ke dalam sistem operasional dan model data, sedangkan
• Data Para Ilmuwan harus bekerja dari perspektif peluang bisnis mencoba untuk menggabungkan data yang dihasilkan dari sumber eksternal, internet hal-hal dan tempat-tempat lain, dan mencoba menyesuaikannya dengan terminology dan model data yang dikelola oleh Pemodelan Data dan Ilmuwan Informasi, yang berarti bahwa,
• 3 tipe actor ini dapat sangat diuntungkan dari platform bersama, dan
• Grafik Pengetahuan akan menjadi bagian penting dari kesesuaian semua ini.
Universitas harus menawarkan kursus antar-disiplin sebanyak mungkin – yang akan menciptakan banyak manfaat bisnis dalam organisasi, di mana para kandidat akan bekerja. Penyediaan Pendidikan dan pelatihan memiliki banyak pekerjaan di masa depan dan beberapa peluang besar untuk memikirkan kembali dan menyesuaikan penawaran mereka. Saya pikir DATAVERSITY menyadari dinamika ini. Saya dapat mendorong vendor alat pemodelan, repositori metadata dan katalog data dll. Untuk memperluas perspektif dan mengambil pendekatan holistic untuk semua itu. Saya akan senang berbagi pemikiran saya dengan mereka. Waktu yang menarik!.
Saya telah menyediakan semua data dan tampilan grafik resolusi tinggi. Daftar tema (“keterampilan”) yang paling lengkap untuk Pemodelan Data masa depan adalah ini :
• Analisis, Kecerdasan Buatan, Data Besar, Analisis Bisnis, Kecerdasan Bisnis, kebutuhan dan proses bisnis.
• Ilmu kognitif, Ilmu Komputer, Analisis Data, Penemuan Data, elemen data, Pemodelan Data, persyaratan data, berbagi data, struktur data, Gudang Data, Manajemen Basis Data, desain basis data, definisi data, dan domain data.
• Arsitektur Perusahaan, perspektif perusahaan, model hubungan entitas, jenis entitas, Pemodelan Grafik, Arsitektur Informasi, rekayasa informasi, Manajemen Siklus Hidup Informasi, representasi informasi, pencarian informasi, sistem informasi, dan teknologi informasi.
• Grafik Pengetahuan, representasi pengetahuan, desain logis, model data logis, model meta, Pemrosesan Bahasa Alami, noenklatur, ontology.
• Model data fisik, penyimpanan data fisik, model prediksi, tipe relasi, konsep relasional, database relasional, dan hubungan.
• Skema, mesin pencarian, Pemodelan Data Semantik, kosakata bersama, teknologi penyimpanan, area subjek, analisis sistem, desain sistem, rekayasa sistem, pemodelan vault, dan visualisasi.
6.2. Proses Pemodelan Data Logis
Pemodelan Data strategis. Banyak organisasi memilih proyek pengembangan IS berdasarkan rencana strategis, termasuk visi dan arsitektur sistem informasi.
Tahap-Tahap Pengembangan Model Logis :
a. Konteks Data model
a) Mencakup hanya entitas dan hubungan
b) Untuk menetapkan ruang lingkup
b. Model data berbasis kunci
a) Menghilangkan hubungan spesifik
b) Termasuk kunci primer dan alternative
c) Tambahkan asosiatif entitas
d) Tepat cardinalities
c. Model data yang sepenuhnya dikaitkan
a) Semua atribut yang tersisa
b) Kriteria subsetting
c) Model data dinormalisasi Metadata data tentang data.
Pertanyaan JRP dan Wawancara Untuk Pemodelan Data
Gambar 6.2.1
• Pengertian UML
UML(Unified Modeling Language) adalah sebuah bahasa untuk menetukan, visualisasi, kontruksi, dan mendokumentasikan artifact (bagian dari informasi yang digunakan atau dihasilkan dalam suatu proses pembuatan perangkat lunak. Artifact dapat berupa model, deskripsi atau perangkat lunak) dari system perangkat lunak, seperti pada pemodelan bisnis dan system non perangkat lunak lainnya. UML merupakan bahasa standar untuk penulisan blueprint software yang digunakan untuk visualisasi, spesifikasi, pembentukan dan pendokumentasian alat-alat dari sistem perangkat lunak.
Jenis-jenis Diagram UML, yaitu :
1. Use Case Diagram
Use case adalah abstraksi dari interaksi antara system dan actor. Use case bekerja dengan cara mendeskripsikan tipe interaksi antara user sebuah system dengan sistemnya sendiri melalui sebuah cerita bagaimana sebuah system dipakai.
Lihat Gambar :
Gambar 6.2.2
Diagram Use Case berguna dalam tiga hal :
a) Menjelaskan fasilitas yang ada (requirement)
b) Komunikasi dengan klien
c) Membuat test dari kasus-kasus secara umum
2. Activity Diagram
Activity diagram menyediakan analis dengan kemampuan untuk memodelkan proses dalam suatu sistem informasi. Activity diagram dapat digunakan untuk alur kerja model, use case individual, atau logika keputusan yang terkandung dalam metode individual3. Activity diagram juga menyediakan pendekatan untuk proses pemodelan paralel. Activity diagram lebih lanjut . Pada dasarnya, diagram aktifitas canggih dan merupakan diagram aliran data yang terbaru. Secara teknis, diagram aktivitas menggabungkan ide-ide proses pemodelan dengan teknik yang berbeda termasuk model acara, statecharts, dan Petri Nets.
Lihat Gambar:
Gambar 6.2.3
3. Package Diagram
Package diagram utamanya digunakan untuk mengelompokkan elemen diagram UML yang berlainan secara bersama-sama ke dalam tingkat pembangunan yang lebih tinggi yaitu berupa sebuah paket. Diagram paket pada dasarnya adalah diagram kelas yang hanya menampilkan paket, disamping kelas, dan hubungan ketergantungan, disamping hubungan khas yang ditampilkan pada diagram kelas.
Sebagai contoh, jika kita memiliki sistem pendaftaran untuk kantor dokter, mungkin masuk akal untuk kelompok kelas pasien dengan kelas sejarah medis pasien bersama-sama untuk membentuk paket kelas pasien. Selain itu, dapat berguna untuk membuat paket perawatan yang mengandung gejala penyakit, penyakit, dan obat-obatan khas yang diresepkan untuk mereka.
Lihat Gambar:
Gambar 6.2.4
4. State Machines Diagram
Statechart diagram digunakan untuk memodelkan perilaku dinamis satu kelas atau objek. Statechart diagram memperlihatkan urutan keadaan sesaat (state) yang dilalui sebuah objek, Kejadian yang menyebabkan sebuah transisi dari suatu state atau aktivitas kepada yang lainnya. Statechart diagram khusus digunakan untuk memodelkan tahap-tahap diskrit dari sebuah siklus hidup objek, sedangkan Activity diagram paling cocok untuk memodelkan urutan aktifitas dalam suatu proses.
Lihat Gambar:
Gambar 6.2.5
5. Sequence Diagram
Sequence diagram menjelaskan interaksi objek yang disusun berdasarkan urutan waktu. Secara mudahnya sequence diagram adalah gambaran tahap demi tahap yang seharusnya dilakukan untuk menghasilkan sesuatu sesuai dengan use case diagram.
Lihat Gambar:
Gambar 6.2.6
6. Class Diagram
Tujuan utama dari class diagram adalah untuk menciptakan sebuah kosa kata yang digunakan oleh analis dan pengguna. Diagram kelas biasanya merupakan hal-hal, ide-ide atau konsep yang terkandung dalam aplikasi. Misalnya, jika anda sedang membangun sebuah aplikasi penggajian, diagram kelas mungkin akan berisi kelas yang mewakili hal-hal seperti karyawan, cek, dan pendaftaran gaji. Diagram kelas juga akan menggambarkan hubungan antara kelas.
Class memiliki 3 area pokok :
1) Name (dan stereotype);
2) Attribute;
3) Method.
Lihat Gambar:
Gambar 6.2.7
7. Communication Diagram
Collaboration diagram menggambarkan interaksi antar objek seperti sequence diagram, tetapi lebih menekankan pada peran masing-masing objek. Setiap message memiliki sequence number, dimana message dari level tertinggi memiliki Nomor 1. Diagram membawa informasi yang sama dengan diagram Sequence, tetapi lebih memusatkan atau memfokuskan pada kegiatan obyek dari waktu pesan itu dikirimkan.
Contoh : Diagram Collaboration “Pemesanan kamar di Hotel”.
Lihat Gambar:
Gambar 6.2.8
8. Composite Structure Diagram
Diagram struktur komposit adalah diagram yang menunjukan struktur internal classifier, termasuk poin interaksinya ke bagian lain dari system. Hal ini menunjukkan konfigurasi dan hubungan bagian, yang bersama-sama melakukan perilaku classifier. Diagram struktur komposit merupakan jenis diagram struktur yang statis dalam UML, yang menggambarkan struktur internal kelas dan kolaborasi.
Struktur komposit dapat digunakan untuk menjelaskan :
– Struktur dari bagian-bagian yang saling berkaitan;
– Run-time struktur yang saling berhubungan.
Lihat Gambar:
Gambar 6.2.9
9. Object Diagram
Object diagram merupakan sebuah gambaran tentang objek-objek dalam sebuah system pada satu titik waktu. Karena lebih menonjolkan perintah-perintah dari pada class, object diagram lebih sering disebut sebagai sebuah diagram perintah.
Lihat Gambar:
Gambar 6.2.10
10. Timing Diagram
Timing Diagram adalah bentuk lain dari interaction diagram, dimana focus utamanya lebih ke waktu. Timing diagram sangat berdaya guna dalam menunjukkan factor pembatas waktu diantara perubahan state pada objek yang berbeda.
Lihat Gambar:
Gambar 6.2.11
11. Component Diagram
Diagram ini bila dikombinasikan dengan diagram penyebaran dapat digunakan untuk menggambarkan distribusi fisik dari modul perangkat lunak melalui jaringan. Misalnya, ketika merancang sistem client-server, hal ini berguna untuk menunjukkan mana kelas atau paket kelas akan berada pada node klien dan mana yang akan berada di server.
Diagram komponen juga dapat berguna dalam merancang dan mengembangkan sistem berbasis komponen. Karena berfokus pada analisis sistem berorientasi objek dan desain.
Lihat Gambar:
Gambar 6.2.12
12. Deployment Diagram
Deployment diagram menggambarkan detail bagaimana komponen di deploy dalam infrastruktur system, dimana komponen akan terletak (pada mesin, server atau piranti keras), bagaimana kemampuan jaringan pada lokasi tersebut, spesifikasi server, dan hal-hal lain yang bersifat fisikal. Hubungan antar node ( misalnya TCP/IP) dan requirement dapat juga didefinisikan dalam diagram ini.
Lihat Gambar:
Gambar 6.2.13
13. Interaction Overview Diagram
Interaction Overview Diagram adalah pecangkolan secara bersama antara activity diagram dengan sequence diagram. Interaction Overview Diagram dapat dianggap sebagai activity diagram dimana semua aktivitas diganti dengan sedikit sequence diagram, atau bisa juga dianggap sebagai sequence diagram yang dirincikan dengan notasi activity diagram yang digunakan untuk menunjukkan aliran pengawasan.
Lihat Gambar:
Gambar 6.2.14
BAB 7. PENUTUP
7.1. Kesimpulan
Dari data dan fakta yang telah dipaparkan diatas maka penulis dapat menyimpulkan bahwa pemodelan data sangat dibutuhkan untuk menentukan dan menganalisis persyaratan data yang diperlukan untuk mendukung proses bisnis perusahaan atau suatu organisasi. Data yang dibutuhkan akan dicatat sebagai data model konseptual dengan definisi data yang terkait dengan perusahaan atau suatu organisasi. Sehingga masalah yang dihadapi oleh perusahaan atau suatu organisasi dapat diselesaikan dengan cara data modeling ini.
7.2 Saran
Meskipun penulis menginginkan kesempurnaan dalam penyusunan buku ini akan tetapi pada kenyataannya masih banyak kekurangan yang perlu penulis perbaiki. Hal ini dikarenakan masih minimnya pengetahuan penulis. Oleh karena itu kritik dan saran yang membangun dari para pembaca sangat penulis harapkan sebagai bahan evaluasi untuk kedepannya.
DAFTAR PUSTAKA
• https://www.dataversity.net/future-data-modeling-whither-data-modeling-education/
• https://herlinnairine.wordpress.com/2014/02/06/entity-relationship-diagram-erd-dan-contoh-kasus/
• http://faizalokieprabowo.blogspot.com/2012/10/transformasi-model-data.html
• https://kasmadteam.wordpress.com/model-data/
• http://41814110124.blog.mercubuana.ac.id/2015/06/20/permodelan-data/
• http://darmastuti.staff.gunadarma.ac.id/Downloads/files/59129/
Data+Flow+Diagram.pdf
• https://www.academia.edu/37502161/KELOMPOK_7_
PEMODELAN_DATA
• https://rifqimulyawan.com/blog/pengertian-data-modelling/
• http://myrianbudiman.blogspot.com/2014/05/pemodelan-data.html
• https://www.nesabamedia.com/pengertian-model-basis-data/
• https://sanitadazira.wordpress.com/dfd-erd-uml/
