Menjelaskan Prinsip Perancangan Perangkat Lunak

 

1) Prinsip Modularitas & Reusability

A. Modularitas

• Sistem dibagi menjadi modul kecil → fokus pada satu fungsi tertentu.

• Memudahkan pengujian, debugging, dan pengembangan paralel.

B. Reusability

• Kode atau modul dapat digunakan kembali dalam proyek lain → hemat waktu dan biaya.

C. DRY (Don't Repeat Yourself)

• Hindari duplikasi kode.

• Solusinya: pakai fungsi, kelas, atau modul yang reusable.

D. KISS (Keep It Simple, Stupid)

• Jaga kode tetap sederhana.

• Kode sederhana = lebih mudah dipahami dan lebih sedikit bug.

2) Prinsip SOLID dalam OOP

Prinsip dasar untuk menciptakan desain OOP yang fleksibel dan maintainable:

A. S - Single Responsibility Principle

• Setiap kelas hanya punya satu tanggung jawab.

• Contoh: Kelas Buku hanya menyimpan info buku, bukan mengatur peminjaman.

B. O - Open/Closed Principle

• Kode harus terbuka untuk ekstensi, tapi tertutup untuk modifikasi.

• Tambah fitur tanpa ubah kode lama → pakai inheritance atau interface.

C. L - Liskov Substitution Principle

• Subclass harus bisa menggantikan superclass tanpa ubah hasil program.

• Jangan pakai subclass yang melanggar perilaku dasar induknya.

D. I - Interface Segregation Principle

• Interface harus spesifik, tidak terlalu umum.

• Misal: jangan gabungkan metode terbang() ke Kendaraan, karena mobil tidak bisa terbang.

E. D - Dependency Inversion Principle

• Kelas tidak boleh bergantung langsung ke kelas lain, tapi ke abstraksi (interface).

• Contoh: OrderService bergantung pada interface PaymentService, bukan kelas spesifik seperti PaypalService.

3) Kohesi dan Coupling

A. High Cohesion

• Modul hanya fokus pada satu fungsi → lebih mudah dipahami & dikelola.

B. Low Coupling

• Modul tidak terlalu tergantung pada modul lain → lebih fleksibel dan aman saat diubah.

C. Dependency Injection

• Cara menyuntikkan dependensi dari luar, bukan dibuat langsung dalam kelas.

• Contoh: Constructor Injection, Setter Injection, Interface Injection.

• Manfaat: mengurangi coupling dan meningkatkan fleksibilitas serta testability.

4. Memvisualisasikan Diagram untuk Perancangan Perangkat Lunak

1) Use Case Diagram

A. Notasi:

• Aktor: Digambarkan dengan gambar orang (User, Admin, dll).

• Use Case: Digambarkan dengan oval (Login, Registrasi, Dll).

• Relasi:

  • <<include>>: Proses wajib terjadi (contoh: Login <<include>> Validasi).

  • <<extend>>: Proses tambahan bersifat opsional (contoh: Promo <<extend>> Pembayaran).

B. Contoh Studi Kasus: Sistem e-Commerce

• Aktor: Konsumen, Member, Admin.

• Use Case: Login, Registrasi, Browse Produk, Isi Keranjang, Kelola Produk.

2) Entity-Relationship Diagram (ERD)

A. Relasi:

• 1:1 → Satu ke satu.

• 1:M → Satu ke banyak. Contoh: 1 User bisa punya banyak Aplikasi.

• M:N → Banyak ke banyak. Contoh: 1 Aplikasi bisa punya banyak Kategori dan sebaliknya.

B. Normalisasi Database

• 1NF: Semua kolom berisi data atomic.

• 2NF: Semua atribut tergantung pada primary key.

• 3NF: Tidak ada ketergantungan antar atribut non-key.

3) Class Diagram

Diagram ini menjelaskan struktur kelas dan hubungannya.

A. Jenis Relasi antar kelas:

• Association: Hubungan biasa antara dua kelas.

• Aggregation: Hubungan "memiliki" tapi objek bisa berdiri sendiri.

• Composition: Hubungan "memiliki" yang kuat. Jika induknya hilang, anaknya ikut hilang.

• Inheritance: Pewarisan atribut dan method dari superclass.

B. Contoh Studi Kasus: Sistem Manajemen Mahasiswa

• Mahasiswa → punya KRS, Nilai, dll.

• Dosen → punya Jadwal.

4) Diagram Lainnya

A. Activity Diagram (Workflow Proses)

• Menunjukkan alur proses sistem dari awal hingga akhir.

• Contoh: Proses pengisian KRS → Validasi Dosen Wali → Pencetakan oleh Staff.

B. Sequence Diagram (Interaksi Antar Objek)

• Menjelaskan urutan pesan yang dikirim antar objek.

• Contoh: User membuka aplikasi → pilih instrumen → sistem load → tampilkan.