ERD Entity Relationship Diagram dalam Perancangan Sistem (Kelompok 6)

Mengenal Entity Relationship Diagram (ERD) untuk Perancangan Database

Di dunia pengembangan sistem informasi, salah satu langkah penting sebelum membangun database adalah membuat gambaran hubungan antar data. Nah, di sinilah Entity Relationship Diagram (ERD) berperan sebagai alat visual yang membantu kita memahami struktur data secara menyeluruh.

Apa Itu ERD?

ERD adalah sebuah diagram yang menunjukkan objek-objek penting dalam sistem (disebut entitas) dan bagaimana mereka saling berhubungan. Dengan ERD, kamu bisa melihat gambaran besar tentang data apa saja yang diperlukan dan bagaimana data tersebut terhubung satu sama lain.

Perbedaan ERD dengan Skema Relasional

1. Meskipun keduanya sama-sama digunakan dalam desain database, ERD dan skema relasional punya fungsi yang berbeda:
2. ERD lebih fokus pada gambaran konseptual, yaitu apa saja entitas dan relasi yang ada.
3. Skema relasional adalah representasi logis yang menunjukkan bagaimana data akan disimpan dalam tabel-tabel di database.
4. Jadi, ERD biasanya dibuat di tahap awal perancangan, sedangkan skema relasional dipakai saat implementasi database.

Komponen Utama dalam ERD

1. Entitas (persegi panjang): Objek utama yang datanya ingin disimpan, misalnya "Mahasiswa" atau "Buku".
2. Atribut (oval): Detail atau karakteristik dari entitas, seperti nama, alamat, atau nomor identitas.
3. Relasi (belah ketupat): Hubungan antara entitas, misalnya "Meminjam" yang menghubungkan entitas "Anggota" dan "Buku".
4. Garis penghubung: Menunjukkan keterkaitan antara entitas, atribut, dan relasi.
5. Selain itu, ada juga konsep Primary Key sebagai atribut unik yang membedakan setiap data, dan Foreign Key yang menghubungkan entitas satu dengan yang lain.

Jenis Hubungan Antar Entitas

1. One to One (1:1): Satu entitas berhubungan dengan satu entitas lain.
2. One to Many (1:M): Satu entitas berhubungan dengan banyak entitas lain.
3. Many to Many (M:N): Banyak entitas berhubungan dengan banyak entitas lain.

Langkah Membuat ERD

1. Tentukan entitas utama yang ada dalam sistem.
2. Identifikasi atribut yang dimiliki setiap entitas.
3. Gambarkan relasi antar entitas beserta jenis kardinalitasnya.
4. Putuskan apakah relasi tertentu perlu dijadikan entitas baru (misalnya transaksi peminjaman).
5. Gunakan tools visual untuk menggambar ERD, seperti MySQL Workbench, Lucidchart, atau Microsoft Visio.

Contoh Kasus: Sistem Informasi Perpustakaan

Misalnya, dalam sistem perpustakaan, entitas yang bisa dibuat adalah:

1. Anggota: dengan atribut ID, nama, alamat, nomor telepon.
2. Buku: dengan atribut ID, judul, pengarang, penerbit.
3. Petugas: yang mengelola transaksi peminjaman.
4. Kategori: sebagai pengelompokkan buku berdasarkan tema.

Relasi yang terjadi misalnya anggota meminjam buku, petugas mencatat transaksi, dan buku dikategorikan sesuai jenisnya. Dengan ERD, hubungan ini bisa divisualisasikan dengan jelas sehingga memudahkan pengembangan sistem.

Kesimpulan

Entity Relationship Diagram adalah alat yang sangat berguna untuk merancang database secara terstruktur dan mudah dipahami. Dengan ERD, kamu bisa memastikan data yang dibutuhkan sudah lengkap dan hubungan antar data sudah tepat, sehingga sistem yang dibuat nanti berjalan efisien dan mudah dikembangkan.

DFD Data Flow Diagram (Kelompok 5)

 Mengenal Data Flow Diagram (DFD): Alat Visual untuk Memahami Alur Data Sistem

Apa Itu Data Flow Diagram (DFD)?

DFD adalah diagram yang menggambarkan bagaimana data bergerak dan diproses dalam sebuah sistem. Bayangkan seperti peta yang menunjukkan dari mana data masuk, bagaimana data diproses, disimpan, dan akhirnya keluar sebagai hasil. Dengan DFD, kita bisa melihat gambaran besar sistem secara visual, jadi lebih mudah dipahami.

Fungsi Utama DFD

• Menjelaskan alur data secara logis sehingga semua orang yang terlibat bisa mengerti bagaimana data mengalir.
• Mempermudah komunikasi antar tim pengembang, karena gambarnya jelas dan sederhana.
• Digunakan pada tahap analisis dan perancangan sistem, sebagai dasar untuk membuat sistem yang efektif.

Simbol-Simbol Penting dalam DFD

• Untuk membuat DFD, ada beberapa simbol yang harus kamu tahu:
• Entitas Eksternal (kotak persegi): Sumber atau tujuan data di luar sistem, misalnya pelanggan atau pemasok.
• Proses (lingkaran): Aktivitas yang mengolah data.
• Arus Data (panah): Menunjukkan arah aliran data antar komponen.
• Penyimpanan Data (dua garis paralel): Tempat menyimpan data, seperti database atau file.

Cara Membuat DFD

• Identifikasi entitas eksternal yang berinteraksi dengan sistem.
• Tentukan proses utama yang terjadi dalam sistem.
• Buat Context Diagram (Level 0) untuk gambaran sistem secara umum.
• Kembangkan ke Level 1 dan Level 2 untuk detail proses yang lebih rinci.

Tools Gratis untuk Membuat DFD

• Draw.io: Gratis dan berbasis web, cocok untuk pemula.
• Lucidchart: Mendukung kolaborasi real-time, bagus untuk kerja tim.
• Microsoft Visio: Profesional dan lengkap, tapi berbayar.
• StarUML: Khusus pemodelan perangkat lunak, lengkap untuk developer.

Kesimpulan

DFD adalah alat yang sangat membantu dalam memahami dan merancang sistem informasi. Dengan visualisasi yang sederhana dan terstruktur, DFD membuat proses komunikasi antar tim jadi lebih lancar dan sistem yang dibuat pun lebih terorganisir.

Prinsip Dan Diagram Untuk Perancangan Perangkat Lunak (kelompok 4)

A. Apa Itu Prinsip Desain dalam Pengembangan Perangkat Lunak?

Perancangan perangkat lunak merupakan tahapan penting dalam pembangunan sistem, yang bertujuan menentukan bagaimana sistem akan bekerja secara teknis. Ini mencakup penentuan struktur sistem, pemilihan komponen, dan pengorganisasian fitur untuk memenuhi kebutuhan pengguna, baik dari sisi fungsi maupun kualitas.

Beberapa prinsip utama yang perlu diperhatikan dalam perancangan perangkat lunak antara lain:

1. Modularitas & Reusability

Modularitas berarti memecah sistem menjadi bagian-bagian kecil (modul) yang berdiri sendiri dan memiliki tugas spesifik. Tiap modul bisa dikembangkan, diuji, dan diperbaiki tanpa mengganggu modul lainnya.

Keuntungannya:

• Lebih mudah dirawat: Perubahan tidak memengaruhi keseluruhan sistem.

• Dapat digunakan kembali: Modul bisa diterapkan di sistem lain.

• Memudahkan pengujian: Karena bisa diuji secara terpisah.

• Mendukung pengembangan bertahap: Cocok untuk proyek jangka panjang.

Reusability artinya kita bisa menggunakan ulang komponen yang sudah dibuat, alih-alih menulis dari nol setiap kali. Misalnya, sebuah modul “pembayaran” bisa dipakai baik di aplikasi e-commerce maupun layanan tiket online.

2. Prinsip DRY (Don't Repeat Yourself)

Tujuan dari prinsip DRY adalah menghindari pengulangan logika yang sama di banyak tempat. Misalnya, jika sistem memiliki aturan perhitungan diskon, sebaiknya dibuat satu fungsi khusus daripada menulis ulang rumus di setiap modul.

Manfaat DRY:

• Lebih sedikit bug karena satu titik perubahan

• Kode lebih mudah dipelihara dan dibaca

• Tidak boros waktu saat pembaruan sistem

3. Prinsip KISS (Keep It Simple, Stupid)

KISS mendorong pengembang untuk membuat solusi sesederhana mungkin. Kompleksitas yang tidak perlu justru menimbulkan masalah di masa depan.

Contoh:
Alih-alih membuat algoritma perhitungan ongkir yang rumit, cukup pakai rumus dasar berdasarkan berat dan jarak jika itu mencukupi kebutuhan bisnis.

4. Prinsip SOLID dalam OOP

SOLID adalah lima prinsip inti dalam desain berorientasi objek yang membantu menciptakan sistem yang mudah dikembangkan dan dirawat:

• Single Responsibility Principle (SRP): Satu class = satu tugas. Contoh: Class InvoicePrinter hanya untuk mencetak, bukan menghitung tagihan.

• Open/Closed Principle: Kode boleh ditambah, tapi jangan diubah. Misalnya, tambah metode baru lewat subclass alih-alih ubah class asli.

• Liskov Substitution Principle: Subclass harus bisa menggantikan superclass tanpa menyebabkan error. Misalnya, jika PengirimanEkspres adalah turunan dari Pengiriman, ia tetap bisa dipakai di tempat yang butuh Pengiriman.

• Interface Segregation Principle: Lebih baik punya banyak interface kecil daripada satu interface besar. Misalnya, ICetak, IScan, dan IFax daripada IMesinMultifungsi.

• Dependency Inversion Principle: Class harus bergantung pada abstraksi (interface), bukan class konkret. Gunakan IPembayaran sebagai penghubung antara sistem dan modul pembayaran tertentu (misalnya Midtrans atau PayPal).

5. Kohesi dan Coupling

• Coupling adalah seberapa erat modul saling bergantung. Semakin longgar (low coupling), semakin baik karena perubahan satu modul tidak memengaruhi yang lain.

  Jenis-jenis Coupling:

  • Data Coupling: Hanya bertukar data.

  • Stamp Coupling: Bertukar struktur data.

  • Control Coupling: Modul mengontrol perilaku modul lain.

  • Common Coupling: Modul berbagi data global.

  • Content Coupling: Satu modul mengakses bagian internal modul lain — paling buruk.

• Cohesion menunjukkan seberapa kuat elemen dalam satu modul bekerja sama untuk menyelesaikan satu tugas.

  Jenis-jenis Kohesi:

  • Functional Cohesion: Semua fungsi dalam modul mendukung satu tujuan — terbaik.

  • Sequential Cohesion: Output satu fungsi menjadi input fungsi lain.

  • Logical Cohesion: Fungsi-fungsi serupa tapi tidak saling terkait langsung.

  • Coincidental Cohesion: Fungsi-fungsi yang dikumpulkan secara acak — terburuk.

Idealnya: Desain dengan kohesi tinggi dan coupling rendah.

6. Dependency Injection (DI)

DI adalah teknik di mana suatu objek tidak membuat sendiri ketergantungannya, melainkan menerimanya dari luar, biasanya lewat constructor atau setter.

Manfaat:

• Mempermudah pengujian (testing)

• Meningkatkan fleksibilitas kode

• Mendukung prinsip SOLID, terutama Dependency Inversion

B. Visualisasi Desain Perangkat Lunak dalam Bentuk Diagram

1. Use Case Diagram

Diagram ini menggambarkan bagaimana pengguna (aktor) berinteraksi dengan sistem dan fungsi-fungsi utama yang bisa mereka jalankan.

• Aktor: Entitas yang menggunakan sistem, seperti pengguna, admin, atau sistem lain.

• Use Case: Fitur utama yang tersedia untuk aktor, seperti “Login”, “Lihat Jadwal”, atau “Bayar Tagihan”.

• Relasi:

  • Include: Fungsi wajib dijalankan dalam use case.

  • Extend: Fitur tambahan yang bisa dijalankan jika dibutuhkan.

Contoh: Aplikasi Booking Tiket Pesawat

• Aktor: Penumpang, Petugas Maskapai

• Use Case: Cari Tiket, Pesan, Bayar, Cetak Tiket

2. Entity-Relationship Diagram (ERD)

ERD menunjukkan hubungan antar entitas di dalam database.

Contoh Relasi:

• 1:1 → Setiap karyawan punya satu ID Karyawan

• 1:M → Satu pelanggan bisa punya banyak pesanan

• M:N → Banyak siswa bisa ikut banyak kegiatan ekstrakurikuler

Normalisasi digunakan untuk mengurangi data ganda dan menjaga konsistensi.

3. Class Diagram

Class diagram digunakan untuk menggambarkan struktur sistem dalam paradigma OOP.

Komponen utama:

• Class: Menunjukkan entitas dan objek

• Atribut: Data yang dimiliki class

• Metode: Fungsi yang dijalankan class

• Relasi antar class:

  • Association: Hubungan langsung

  • Aggregation: Hubungan “memiliki” tapi objek bisa berdiri sendiri

  • Composition: Hubungan lebih kuat, jika class utama dihapus, class bagian ikut hilang

Contoh: Aplikasi Manajemen Sekolah

• Class Siswa: nama, NIS, nilai()

• Class Kelas: kode, nama

• Class Guru: nama, mengajar()

Kebutuhan Perangkat Lunak Dan Teknik Analisis Kebutuhan Perangkat Lunak(kelompok 3)

 

Apa Itu Kebutuhan Perangkat Lunak?

Kebutuhan perangkat lunak adalah segala hal yang harus dimiliki atau dijalankan oleh suatu sistem agar mampu memenuhi harapan serta kebutuhan pengguna dan pihak yang berkepentingan. Kebutuhan ini menjadi pondasi penting dalam proses pembuatan perangkat lunak yang tepat guna, handal, dan efisien.

Kebutuhan tersebut diklasifikasikan ke dalam tiga kelompok utama:

1. Kebutuhan Fungsional

Ini adalah perilaku atau fungsi inti yang harus tersedia dalam sistem. Fungsionalitas ini memungkinkan pengguna menjalankan aktivitas utama.
Contoh: Pada aplikasi pemesanan makanan online, fitur seperti pencarian restoran, pemesanan makanan, dan pelacakan pengiriman merupakan bagian dari kebutuhan fungsional.

2. Kebutuhan Non-Fungsional

Berhubungan dengan aspek kualitas dari sistem itu sendiri—bagaimana sistem bekerja, bukan apa yang dikerjakannya.
Contoh: Kemampuan aplikasi memproses banyak pesanan dalam waktu bersamaan, tingkat keamanan data pelanggan, atau kecepatan respon sistem.

3. Kebutuhan Domain

Merupakan aturan atau standar khusus yang berlaku dalam konteks industri tertentu.
Contoh: Dalam sistem rumah sakit, keharusan menggunakan standar ICD-10 untuk klasifikasi penyakit merupakan kebutuhan domain.

Teknik untuk Menganalisis Kebutuhan

Agar perangkat lunak yang dibuat benar-benar relevan dan sesuai dengan harapan, dibutuhkan pendekatan sistematis untuk menggali kebutuhan. Beberapa metode yang sering dipakai antara lain:

• Wawancara & Survei: Berbicara langsung dengan pengguna seperti kasir atau manajer restoran untuk memahami proses bisnis.

• Observasi Lapangan: Mengamati bagaimana sistem lama digunakan dalam operasional nyata.

• Prototyping: Menyusun sketsa awal sistem, seperti tampilan aplikasi kasir digital, untuk diuji coba secara cepat.

• JAD (Joint Application Development): Sesi kolaboratif antara pengembang, pengguna, dan manajer untuk menggali kebutuhan secara mendalam.

Langkah-Langkah dalam Analisis Kebutuhan

1. Identifikasi Pihak Terkait: Menentukan siapa saja yang berkepentingan terhadap sistem (misalnya pelanggan, pegawai, dan manajemen).

2. Pengumpulan Informasi: Menggunakan metode-metode di atas untuk mendapatkan data tentang kebutuhan pengguna.

3. Evaluasi Kebutuhan: Memeriksa informasi yang dikumpulkan untuk menyaring dan memvalidasi yang benar-benar penting.

4. Dokumentasi Kebutuhan: Menulis kebutuhan secara sistematis agar dapat menjadi pedoman saat pengembangan.

5. Validasi: Memastikan semua pihak setuju bahwa kebutuhan yang telah dicatat sesuai dengan keinginan mereka.

Mengelola Perubahan Kebutuhan

Kebutuhan perangkat lunak bisa berubah seiring waktu. Oleh karena itu, pengelolaan yang baik diperlukan untuk menjaga stabilitas proyek:

• Pencatatan yang Rapi: Menyimpan kebutuhan dalam dokumen yang jelas dan terstruktur.

• Tinjauan Berkala: Melakukan pengecekan ulang atas kebutuhan seiring berjalannya waktu.

• Penentuan Prioritas: Menyusun urutan pengerjaan berdasarkan tingkat pentingnya kebutuhan.

• Manajemen Perubahan: Menyesuaikan sistem dengan perubahan kebutuhan tanpa merusak struktur yang sudah dibangun.

Dari Kebutuhan Menuju Rancangan Sistem

Setelah kebutuhan dikumpulkan dan disetujui, langkah berikutnya adalah mengubahnya menjadi desain sistem yang konkret.

Prinsip-Prinsip Desain:

• Modularitas: Memecah sistem menjadi bagian kecil yang saling terpisah.

• Reusability: Komponen dapat digunakan ulang dalam proyek lain.

• Maintainability: Sistem dirancang agar mudah diperbaiki jika ada gangguan.

Jenis Desain dalam Perangkat Lunak:

• Desain Arsitektur: Menentukan struktur besar sistem, seperti penggunaan microservices atau MVC.

• Desain Modular: Pengelompokan fitur menjadi modul seperti "Manajemen Menu", "Pembayaran", dan "Laporan Penjualan".

• Desain Data: Menggunakan diagram basis data seperti ERD atau skema tabel NoSQL.

• Desain Antarmuka: Membuat UI/UX untuk aplikasi serta API bagi integrasi.

• Desain Algoritma: Menyusun logika sistem dalam bentuk flowchart atau pseudocode.

Pendekatan Desain

• Object-Oriented Design (OOD): Pendekatan berbasis objek, ideal untuk sistem yang kompleks dan dinamis.

• Structured Design: Pendekatan terstruktur yang cocok untuk sistem dengan alur yang jelas dan linier.

Dokumentasi yang Perlu Disiapkan

• SRS (Software Requirements Specification): Berisi semua kebutuhan yang telah dianalisis dan disepakati.

• SDD (Software Design Document): Menjelaskan secara rinci desain teknis sistem.

Studi Kasus: Aplikasi Pemesanan Makanan Online

Untuk ilustrasi nyata, kita bisa ambil contoh aplikasi pemesanan makanan. Sistem ini dibangun dengan:

• Arsitektur microservices: Agar fitur seperti pencarian restoran, pembayaran, dan pelacakan bisa berdiri sendiri dan dikembangkan terpisah.

• Model C4: Untuk menggambarkan struktur sistem dari level tinggi hingga detail teknis.

• Dokumentasi SRS & SDD: Untuk mendefinisikan kebutuhan pengguna dan cara teknis sistem dijalankan.

• Desain Berorientasi Objek & Modular: Masing-masing fitur dikembangkan sebagai objek dan modul mandiri.