PRINSIP DAN DIAGRAM UNTUK PERANCANGAN PERANGKAT LUNAK (kelompok 4)

A.Pengertian  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. Proses desain ini melibatkan pengambilan keputusan tentang bagaimana sistem akan dibangun, serta memilih komponen dan struktur yang terbaik untuk memenuhi kebutuhan fungsional dan non-fungsional.

Berikut adalah beberapa prinsip utama dalam desain sistem perangkat lunak:

1. Prinsip Modularitas & Reusability

Modularitas adalah pemecahan sistem menjadi bagian-bagian kecil (modul) yang independen dan memiliki fungsi khusus.

Setiap modul berinteraksi melalui antarmuka yang terdefinisi dengan baik.

Keuntungan Modularitas:

• Pemeliharaan lebih mudah: Perubahan hanya di modul terkait tanpa ganggu sistem lain.

• Reusabilitas: Modul dapat digunakan kembali di proyek lain.

• Pengujian lebih mudah: Modul bisa diuji satu per satu.

• Skalabilitas: Sistem lebih fleksibel untuk berkembang.

Reusabilitas adalah kemampuan menggunakan kembali komponen perangkat lunak yang sudah ada, sehingga:

• Efisiensi meningkat: Pengembang tidak perlu membuat semuanya dari awal.

• Biaya lebih rendah: Mengurangi sumber daya yang dibutuhkan.

DRY (Don't Repeat Yourself)

Prinsip DRY mengajarkan pengembang untuk menghindari duplikasi kode dalam sistem.

Setiap logika atau pengetahuan hanya boleh ada di satu tempat, agar:

• Mengurangi redundansi

• Memudahkan pemeliharaan

• Mencegah kesalahan akibat pembaruan yang tidak konsisten

DRY sangat erat kaitannya dengan pemrograman modular, di mana fungsi, kelas, atau modul dibuat reusable untuk meningkatkan efisiensi dan keterbacaan kode.

KISS (Keep It Simple, Stupid)

Prinsip KISS mendorong pengembang untuk membuat desain yang sederhana dan lugas, menghindari kerumitan yang tidak perlu.

Dengan menjaga kesederhanaan:

• Sistem lebih mudah dipahami dan dipelihara

• Mengurangi risiko kesalahan

• Memudahkan kolaborasi antar anggota tim

KISS bukan berarti mengabaikan kebutuhan penting, melainkan menemukan solusi paling sederhana yang tetap memenuhi tujuan proyek.

2.Prinsip SOLID dalam OOP

Single Responsibility Principle

Prinsip ini menyatakan bahwa setiap class hanya boleh memiliki satu tanggung jawab dan satu alasan untuk berubah. Misalnya, class yang mendefinisikan struktur data hanya berubah jika strukturnya diubah, sedangkan class business logic berubah jika logikanya berubah. Salah satu contoh penerapan prinsip ini adalah menggunakan Repository Pattern.

Open/Closed Principle

Kode harus terbuka untuk ekstensi namun tertutup untuk modifikasi. Artinya, kita harus dapat menambahkan fitur baru tanpa mengubah kode yang sudah ada. Ini bisa dicapai dengan menggunakan abstraksi seperti interface atau abstract class, sehingga meminimalisir resiko munculnya bug saat menambahkan fitur baru.

Liskov Substitution Principle

Subclass harus dapat menggantikan superclass tanpa mempengaruhi fungsi program. Subclass harus menjaga konsistensi perilaku, parameter, dan nilai kembalian (return value) yang sama seperti superclass.

Interface Segregation Principle

Dalam prinsip ini, lebih baik membuat banyak interface kecil dan spesifik dibandingkan satu interface besar. Ini mencegah client dari dipaksa menggunakan metode yang tidak mereka butuhkan. Jika perlu menambahkan fungsi baru, lebih baik membuat interface baru daripada mengubah yang lama.

Dependency Inversion Principle

Prinsip ini menyatakan bahwa kelas harus bergantung pada abstraksi, bukan pada implementasi konkret. Modul tingkat tinggi dan rendah harus sama-sama bergantung pada abstraksi, bukan detail teknis. Komunikasi antar kelas dilakukan melalui interface agar fleksibilitas lebih terjaga dan ketergantungan antar kelas berkurang.

Kohesi dan Coupling dalam Perangkat Lunak

Coupling adalah tingkat ketergantungan antar modul dalam perangkat lunak.

Coupling rendah berarti modul bersifat independen, sedangkan coupling tinggi menunjukkan modul-modul saling bergantung erat, sehingga perubahan pada satu modul dapat memengaruhi modul lain.

Jenis-jenis Coupling:

• Data Coupling: Modul hanya bertukar data tanpa informasi tambahan.

• Stamp Coupling: Struktur data lengkap diteruskan antar modul.

• Control Coupling: Modul berbagi informasi kontrol.

• External Coupling: Modul bergantung pada sistem luar atau perangkat keras tertentu.

• Common Coupling: Modul berbagi data global.

• Content Coupling: Modul dapat langsung mengubah data atau kontrol modul lain, yang harus dihindari.

Keuntungan coupling rendah: mempermudah pemeliharaan, meningkatkan modularitas, dan mempercepat skalabilitas.

Kerugian coupling tinggi: meningkatkan kompleksitas dan mengurangi fleksibilitas sistem.

Cohesion mengacu pada seberapa erat elemen dalam suatu modul bekerja sama untuk satu tujuan.

Kohesi tinggi menunjukkan bahwa semua elemen dalam modul saling berhubungan erat, sedangkan kohesi rendah berarti elemen-elemen tidak berfokus pada satu tugas tertentu.

Jenis-jenis Cohesion:

• Functional Cohesion: Setiap elemen penting untuk satu komputasi (ideal).

• Sequential Cohesion: Output satu elemen menjadi input untuk elemen lain.

• Communicational Cohesion: Elemen bekerja pada data masukan/keluaran yang sama.

• Procedural Cohesion: Elemen menjalankan urutan prosedur.

• Temporal Cohesion: Elemen digabung karena waktu eksekusi yang sama.

• Logical Cohesion: Elemen terkait secara logis, bukan fungsional.

• Coincidental Cohesion: Elemen tidak berhubungan, bentuk kohesi terburuk.

• Informational Cohesion: Elemen bekerja berdasarkan struktur data tertentu.

Keuntungan kohesi tinggi: meningkatkan keterbacaan, isolasi kesalahan, dan kemudahan pemeliharaan.

Kerugian kohesi rendah: menyebabkan duplikasi kode dan mengurangi fungsionalitas modul.

High Cohesion & Low Coupling adalah kombinasi ideal dalam desain perangkat lunak.

Dengan kohesi tinggi dan coupling rendah, sistem menjadi lebih stabil, fleksibel, mudah dipelihara, dan lebih siap untuk dikembangkan.

Dependency Injection juga diterapkan untuk mendukung prinsip ini, di mana objek mendapatkan ketergantungannya dari luar, bukan membuat sendiri, sehingga memperkuat fleksibilitas sistem.

B.Memvisualisasikan Diagram untuk Perancangan Perangkat Lunak

1.Diagram Use Case

Use Case Diagram adalah representasi visual dalam UML yang menggambarkan interaksi antara aktor (pengguna atau sistem eksternal) dengan sistem. Diagram ini menunjukkan bagaimana pengguna menggunakan berbagai fungsi (use case) dalam sistem.

• Aktor: Entitas eksternal yang berinteraksi dengan sistem (contoh: pelanggan, admin).

• Use Case: Fungsi spesifik yang dapat dilakukan pengguna, misalnya "Pesan Produk" atau "Check-out".

• Relasi: Ada relasi include (menggabungkan fungsionalitas) dan extend (menambahkan perilaku baru).
  Diagram ini penting untuk mendefinisikan fungsionalitas sistem secara umum.

Contoh Use Case Sistem Belanja Online:

Aktor: Pelanggan dan Admin.

Kasus penggunaan: Telusuri Produk, Tambahkan ke Keranjang, Check-out, Kelola Inventaris.

2.Entity-Relationship Diagram (ERD)

ERD digunakan untuk memodelkan hubungan antar entitas dalam basis data.

Relasi dalam ERD:

• 1:1 (Satu ke Satu): Contoh, satu orang memiliki satu NIK.

• 1:M (Satu ke Banyak): Contoh, satu dosen mengajar banyak mata kuliah.

• M:N (Banyak ke Banyak): Contoh, mahasiswa mengambil banyak mata kuliah dan sebaliknya.

Normalisasi Database:

Normalisasi bertujuan mengurangi redundansi data dan memastikan data disimpan pada tabel yang tepat agar lebih fleksibel dan konsisten.

3.Class Diagram

Class Diagram menggambarkan struktur sistem berorientasi objek, menunjukkan class, atribut, metode, dan relasi antar class.

• Association: Hubungan statis antara dua class.

• Aggregation: Hubungan di mana satu class merupakan bagian dari class lain, tetapi tetap bisa berdiri sendiri.

Class Diagram biasanya dibuat sebelum tahap produksi untuk menjadi panduan bagi programmer.