(5) Data Flow Diagram (DFD)

 A. Definisi Data Flow Diagram (DFD)

Data Flow Diagram (DFD) DFD adalah suatu model logika data atau proses yang dibuat untuk menggambarkan darimana asal data dan kemana tujuan data yang keluar dari sistem, dimana data disimpan, proses apa yang menghasilkan data tersebut, dan interaksi antara data yang tersimpn, dan proses yang dikenakan pada data tersebut. (Rita Afyenni, 2015). Menurut Sukamto dan Shalahuddin (2015:72).

Fungsi DFD dalam perancangan system

DFD sering digunakan untuk menggambarkan suatu sistem yang telah ada atau sistem yang baru yang akan dikembangkan secara logika dan menjelaskan arus data dari mulai pemasukan sampai dengan keluaran data tingkatan diagram arus data mulai dari diagram konteks yang menjelaskan secara umum suatu sistem atau batasan sistem dari level 0 dikembangkan menjadi level 1 sampai sistem tergambarkan secara rinci.

Contoh DFD :



B. Perbedaan antara DFD vs UML Activity Diagram
1. DFD (Data Flow Diagram)

DFD itu semacam peta aliran data. Biasanya dipakai untuk menggambarkan bagaimana
data bergerak di dalam sistem.
• Fokus utama: Data yang masuk, diproses, dan keluar dari sistem.
• Digunakan oleh: Analis sistem, pengembang untuk memahami alur data.
• Simbol-simbol yang dipakai:

➢ Proses: lingkaran (oval): aktivitas yang mengolah data.
➢ Data store(dua garis paralel ): tempat penyimpanan data.
➢ External entity (kotak) : orang atau sistem luar yang berinteraksi.
➢ Data flow (panah) :aliran data antar komponen.

Contoh sederhana: kamu login ke aplikasi. DFD akan tunjukkan data username & password
dikirim ke sistem, dicek di database, lalu hasilnya (sukses/gagal) dikirim kembali ke
pengguna.
2. UML Activity Diagram
Activity Diagram adalah bagian dari UML (Unified Modeling Language) yang
menggambarkan alur aktivitas atau proses kerja dalam sistem.
• Fokus utama: Langkah-langkah aktivitas (flow) dalam sebuah proses.
• Digunakan oleh: P
• engembang, desainer sistem, untuk model proses bisnis atau logika aplikasi.
• Simbol-simbol yang dipakai:
➢ Start node (bulatan hitam) :tanda mulai proses.
➢ Activity (persegi bulat sudut): tindakan/aktivitas.
➢ Decision (belah ketupat ): pilihan/percabangan.
➢ Arrow (panah): arah alur proses.
➢ End node (bulatan dengan lingkaran): tanda akhir proses.

Contoh sederhana: kamu belanja online. Activity Diagram bisa tunjukin langkah-
langkahnya seperti pilih produk lalu checkout lalu isi alamat selanjutnya bayar dan selesai.
 
C. Simbol-simbol dalam DFD

Menurut Jogiyanto Hartono, tahun 2005 dalam bukunya Basia Data ada beberapa simbol
digunakan pada DFD untuk mewakili :

1) Entitas Eksternal(External Entity)
Entitas Eksternal(external entity) merupakan entitas(entity) di lingkungan luar
sistem yang dapat berupa orang, organisasi, atau sistem lain yang berada pada lingkungan
luarnya yang memberikan input atau menerima output dari sistem.

2) Proses (Process)
Proses (process) menunjukan pada bagian yang mengubah input menjadi output, yaitu
menunjukan bagaimana satu atau lebih input diubah menjadi beberapa output. Setiap
proses mempunyai nama, nama dari proses ini menunjukan apa yang dikerjakan proses.

3) Arus Data (Data Flow)
Arus Data (data flow) di DFD diberi simbol suatu panah. Arus data ini mengalir di antara
proses, simpan data dan kesatuan luar. Arus data ini menunjukan arus dari data yang
dapat berupa masukan untuk sistem atau hasil dari proses sistem.

4) Simpanan Data (Data Store)
Data Store merupakan simpanan dari data yang dapat berupa suatu file atau database pada
sistem komputer.

2.Langkah Teknik Pembuatan Pembuatan Data Flow Diagram (DFD)
a. Identfikasi Entitas eksternal
b. Tentukan Proses Utama dalam Sistem
c. Buat Context Diagram (DFD Level 0)
d. Pecah Context Diagram ke dalam DFD Level 1
e. DFD Level 2





(4) PRINSIP DAN DIAGRAM UNTUK PERANCANGAN PERANGKAT LUNAK

 A. Prinsip Perancangan Perangkat Lunak

Desain sistem perangkat lunak adalah proses merancang arsitektur dan komponen

perangkat lunak yang dapat memecahkan masalah yang dihadapi pengguna atau organisasi.

1. Prinsip Modularitas & Reusability

  • Modularitas adalah prinsip desain yang mengedepankan pemecahan sistem menjadi

bagian-bagian yang lebih kecil dan independen, yang disebut modul. Setiap modul memiliki

fungsi atau tanggung jawab tertentu dan berinteraksi dengan modul lain melalui antarmuka

yang terdefinisi dengan baik.

  • Reusability kemampuan perangkat untuk lunak digunakan adalah kembali komponen

perangkat lunak yang ada atau mudah tersedia untuk mengurangi waktu dan biaya untuk

komputasi dan sumber daya manusia

  • DRY (Don’t Repeat Yourself)

Don't Repeat Yourself (DRY) adalah prinsip pengembangan perangkat lunak yang

mendorong pengembang untuk menghindari duplikasi kode dalam suatu sistem.

  • KISS (Keep It Simple, Stupid)

Prinsip KISS betapa pentingnya kemudahan dalam desain perangkat lunak. Prinsip ini

mendorong pengembang untuk menghindari kerumitan yang tidak perlu dan menciptakan

solusi yang lugas dan mudah dipahami.


2. Prinsip SOLID dalam OOP

  • Single Responsibility Princip

principle artinya setiap class wajib hanya memiliki satu tanggung jawab, dan hanya

memiliki satu alasan untuk diubah. 

  • Open/Closed Principle

Dengan menerapkan Open-close principle kita harusnya bisa menambahkan fitur baru

tanpa harus mengubah kode lama yang sudah ditulis sebelumnya.

  • Liskov Substitution Principle

Konsep ini terkait dengan proses inheritance suatu fungsi atau objek.

  • Dependency Inversion Principle

Prinsip DIP mengatakan bahwa kelas seharusnya bergantung pada abstraksi, bukan pada

implementasi.


3. Kohesi dan Coupling

  • Kopling mengacu pada tingkat saling ketergantungan antara modul perangkat lunak.

Kopling yang tinggi berarti bahwa modul-modul saling terhubung erat dan perubahan dalam

satu modul dapat memengaruhi modul-modul lainnya. Kopling yang rendah berarti bahwa

modul-modul bersifat independen, dan perubahan dalam satu modul memiliki dampak yang

kecil pada modul-modul lainnya.

Berikut ini adalah jenis-jenis Kopling:

a. Penggabungan Data: Jika ketergantungan antara modul didasarkan pada fakta bahwa

mereka berkomunikasi dengan hanya mengirimkan data, maka modul tersebut

dikatakan sebagai penggabungan data. Dalam penggabungan data, komponen-

komponennya independen satu sama lain dan berkomunikasi melalui data. Komunikasi

modul tidak berisi data tramp. Contoh-sistem penagihan pelanggan.

b. Stamp Coupling Dalam stamp coupling, struktur data lengkap diteruskan dari satu

modul ke modul lainnya. Oleh karena itu, hal ini melibatkan data tramp. Hal ini

mungkin diperlukan karena faktor efisiensi - pilihan ini dibuat oleh desainer yang

cerdas, bukan programmer yang malas.

c. Kopling Kontrol: Jika modul berkomunikasi dengan cara menyampaikan informasi

kontrol, maka modul tersebut disebut sebagai kopling kontrol. Kopling kontrol dapat

dikatakan buruk jika parameter menunjukkan perilaku yang sama sekali berbeda, dan

dapat dikatakan baik jika parameter memungkinkan pemfaktoran dan penggunaan

kembali fungsionalitas. Contoh- fungsi sortir yang menggunakan fungsi perbandingan

sebagai argumen.

d. Kopling Eksternal: Dalam kopling eksternal, modul-modul bergantung pada modul-

modul lain, yang berada di luar perangkat lunak yang sedang dikembangkan atau pada

jenis perangkat keras tertentu. Misalnya protokol, berkas eksternal, format perangkat,

dll.

e. Common Coupling: Modul-modul memiliki data bersama seperti struktur data global.

Perubahan dalam data global berarti menelusuri kembali ke semua modul yang

mengakses data tersebut untuk mengevaluasi dampak perubahan. Jadi, ada beberapa

kelemahan seperti kesulitan dalam menggunakan kembali modul, berkurangnya

kemampuan untuk mengendalikan akses data, dan berkurangnya pemeliharaan.

f. Content Coupling: Dalam content coupling, satu modul dapat mengubah data modul

lain, atau aliran kontrol diteruskan dari satu modul ke modul lainnya. Ini adalah bentuk

coupling terburuk dan harus dihindari.

g. Kopling Temporal: Kopling temporal terjadi ketika dua modul bergantung pada waktu

atau urutan kejadian, seperti satu modul perlu dijalankan sebelum modul lainnya. Jenis

kopling ini dapat mengakibatkan masalah desain dan kesulitan dalam pengujian dan

pemeliharaan.

h. Kopling Berurutan: Kopling berurutan terjadi saat output dari satu modul digunakan

sebagai input modul lain, yang menciptakan rantai atau urutan ketergantungan. Jenis

kopling ini sulit dipertahankan dan dimodifikasi.

i. Kopling Komunikasi: Kopling komunikasi terjadi ketika dua atau lebih modul berbagi

mekanisme komunikasi yang sama, seperti antrean pesan atau basis data yang sama.

Jenis kopling ini dapat menyebabkan masalah kinerja dan kesulitan dalam debugging.

  • Kohesi mengacu pada tingkat di mana elemen-elemen dalam suatu modul bekerja sama untuk

memenuhi satu tujuan yang ditetapkan dengan baik. Kohesi yang tinggi berarti bahwa elemen-

elemen saling terkait erat dan terfokus pada satu tujuan, sedangkan kohesi yang rendah berarti

bahwa elemen-elemen saling terkait secara longgar dan melayani berbagai tujuan.

Berikut ini adalah jenis-jenis Kohesi:

a. Kohesi Fungsional: Setiap elemen penting untuk satu komputasi terkandung dalam

komponen. Kohesi fungsional menjalankan tugas dan fungsinya. Ini adalah situasi yang

ideal.

b. Kohesi Berurutan: Suatu elemen mengeluarkan sejumlah data yang menjadi masukan

bagi elemen lainnya, yaitu aliran data antar bagian. Hal ini terjadi secara alami dalam

bahasa pemrograman fungsional.

c. Kohesi Komunikasi: Dua elemen beroperasi pada data masukan yang sama atau

berkontribusi terhadap data keluaran yang sama. Contoh: memperbarui catatan dalam

basis data dan mengirimkannya ke printer.

d. Kohesi Prosedural: Elemen-elemen kohesi prosedural memastikan urutan pelaksanaan.

Tindakan masih terhubung secara lemah dan tidak mungkin dapat digunakan kembali.

Misalnya menghitung IPK siswa, mencetak catatan siswa, menghitung IPK kumulatif,

mencetak IPK kumulatif.

e. Kohesi Temporal: Elemen-elemen tersebut saling terkait berdasarkan waktu yang

terlibat. Modul yang terhubung dengan kohesi temporal mengharuskan semua tugas

dieksekusi dalam rentang waktu yang sama. Kohesi ini berisi kode untuk

menginisialisasi semua bagian sistem. Banyak aktivitas berbeda terjadi, semuanya

dalam waktu satuan.

f. Kohesi Logis: Elemen-elemen tersebut terkait secara logis dan tidak secara fungsional.

Misalnya, komponen A membaca input dari pita, disk, dan jaringan. Semua kode untuk

fungsi-fungsi ini ada dalam komponen yang sama. Operasi-operasinya terkait, tetapi

fungsinya sangat berbeda.

g. Kohesi Kebetulan: Elemen-elemen tidak terkait (tidak berhubungan). Elemen-elemen

tidak memiliki hubungan konseptual selain lokasi dalam kode sumber. Itu tidak

disengaja dan merupakan bentuk kohesi terburuk. Contoh: cetak baris berikutnya dan

balikkan karakter string dalam satu komponen.

h. Kohesi Prosedural: Jenis kohesi ini terjadi ketika elemen atau tugas dikelompokkan

bersama dalam sebuah modul berdasarkan urutan pelaksanaannya, seperti modul yang

menjalankan serangkaian prosedur terkait dalam urutan tertentu. Kohesi prosedural

dapat ditemukan dalam bahasa pemrograman terstruktur.

i. Kohesi Komunikasi: Kohesi komunikasi terjadi ketika elemen atau tugas

dikelompokkan bersama dalam sebuah modul berdasarkan interaksinya satu sama lain,

seperti modul yang menangani semua interaksi dengan sistem atau modul eksternal

tertentu. Jenis kohesi ini dapat ditemukan dalam bahasa pemrograman berorientasi

objek.

j. Kohesi Temporal: Kohesi temporal terjadi ketika elemen atau tugas dikelompokkan

bersama dalam sebuah modul berdasarkan waktu atau frekuensi pelaksanaannya,

seperti modul yang menangani semua tugas periodik atau terjadwal dalam sebuah

sistem. Kohesi temporal umumnya digunakan dalam sistem real-time dan embedded.

k. Kohesi Informasional: Kohesi informasional terjadi ketika elemen atau tugas

dikelompokkan bersama dalam sebuah modul berdasarkan hubungannya dengan

struktur data atau objek tertentu, seperti modul yang beroperasi pada tipe data atau

objek tertentu. Kohesi informasional umumnya digunakan dalam pemrograman

berorientasi objek.

(3) KEBUTUHAN PERANGKAT LUNAK

 1. Kebutuhan perangkat lunak

Kebutuhan perangkat lunak adalah proses penting dalam pengembangan aplikasi,

termasuk aplikasi perpustakaan digital. Proses ini melibatkan identifikasi, analisis, dan

spesifikasi kebutuhan yang diperlukan oleh pengguna dan pemangku kepentingan.

2. Jenis-Jenis Kebutuhan Perangkat Lunak


 Kebutuhan Fungsional

Kebutuhan fungsional adalah fitur-fitur yang harus disediakan oleh

perangkat lunak untuk memenuhi tujuan pengguna. Contohnya, dalam

aplikasi perpustakaan digital, kebutuhan fungsional meliputi:

o Pencarian Buku: Kemampuan untuk mencari buku berdasarkan

judul, pengarang, atau kategori.

o Peminjaman Buku Digital: Fitur untuk meminjam buku digital

dan mengelola masa peminjaman.

o Pengelolaan Koleksi: Kemampuan untuk menambah, mengedit,

dan menghapus koleksi buku digital.


 Kebutuhan Non-Fungsional

Kebutuhan non-fungsional adalah kriteria yang tidak terkait langsung

dengan fitur, seperti:

o Keamanan: Perlindungan data pengguna dan koleksi digital dari

akses tidak sah.

o Kinerja: Kemampuan aplikasi untuk menangani banyak pengguna

secara bersamaan tanpa penurunan kinerja.

o Skalabilitas: Kemampuan aplikasi untuk berkembang sesuai

dengan pertumbuhan koleksi dan pengguna.


 Kebutuhan Domain

Kebutuhan domain terkait dengan aturan dan standar yang berlaku dalam

industri perpustakaan, seperti standar metadata untuk pengatalogan buku.


3.Teknik Analisa Kebutuhan Perangkat Lunak

 Wawancara

 Kuesioner

 Observasi

 Studi Dokumen

 Prototyping

 JAD (Joint Application Development)


4.Proses Analisa Kebutuhan Perangkat Lunak

 Identifikasi Pemangku Kepentingan

 Pengumpulan Kebutuhan

 Analisis Kebutuhan

 Spesifikasi Kebutuhan

 Validasi Kebutuhan


5. Pengelolaan Kebutuhan Perangkat Lunak

 Dokumentasi Kebutuhan

 Validasi Kebutuhan

 Prioritas Kebutuhan

 Manajemen Perubahan Kebutuhan


6. Konsep Perancangan Perangkat Lunak

Definisi dan Perandalam SDLC:

Perancangan perangkat lunak adalah proses penting dalam Software Development

Life Cycle (SDLC) yang melibatkan pembuatan rencana terperinci sebelum implementasi

kode. Tujuannya adalah memastikan bahwa perangkat lunak sesuai dengan kebutuhan

pengguna dan dapat diimplementasikan secara efektif.

7. Pendekatan Perancangan

Top-Down vs. Bottom-Up:

 Top-Down: Dimulai dari tingkat tertinggi, memecah sistem menjadi modul-modul

kecil. Cocok untuk proyek besar dengan kebutuhan integrasi yang kompleks.

 Bottom-Up: Dimulai dari komponen kecil, mengembangkan dan menguji setiap

modul secara individual sebelum diintegrasikan. Fleksibel dan cepat dalam

pengembangan.

Object-Oriented Design (OOD) vs. Structured Design:

 OOD: Berfokus pada objek dan interaksinya, memudahkan pengembangan sistem

yang kompleks dan modular.

 Structured Design: Menggunakan struktur yang terorganisir dan terstruktur, cocok

untuk sistem yang lebih sederhana dan linear.

8. Dokumentasi Perancangan

Software Requirement Specification (SRS): Dokumen yang mendefinisikan kebutuhan

fungsional dan non-fungsional perangkat lunak.

Software Design Document (SDD): Dokumen yang menjelaskan desain sistem secara rinci,

termasuk arsitektur dan komponen-komponennya.