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()