Konsep modularitas dalam perangkat lunak komputer telah didukung selama hampir empat dekade. Arsitektur perangkat lunak memasukkan modularitas, dimana perangkat lunak dibagi ke dalam komponen-komponen bernama dan dapat dipanggil terpisah. Lima kriteria yang memungkinkan kita mengevaluasi suatu metode desain dengan merujuk pada kemampuannya untuk menentukan sistem modular yang efektif. Dekomposibilitas modular. Bila metode desain memberikan suatu mekanisme sistematis untuk melakukan dekomposisi terhadap masalah menjadi submasalah-submasalah, maka metode desain akan mengurangi kompleksitas keseluruhan masalah, sehingga dapat mencapai solusi modular efektif. Komposabilitas modular, bila suatu metode desain memungkinkan komponen-komponen desain (reusable) yang ada untuk dipasang ke dalam sebuah sistem baru, maka metode desain akan menghasilkan suatu solusi modular yang tidak berulang. Kemampuan pemahaman modular, jika sebuah modul dapat dipahami sebagai unit yang berdiri sendiri (tanpa referensi dari modul lain), maka modul akan lebih mudah dibangun dan diubah. Kontinuitas modular, Bila perubahan kecil pada persyaratan sistem menyebabkan perubahan kecil pada modul individual dan bukan perubahan sistem secara luas, maka pengaruh dari efek samping yang disebabkan oleh kesalahan oleh perubahan dapat diminimalkan. Proteksi modular, Bila terjadi kondisi yang menyimpang pada modul tersebut, pengaruh dari efek samping yang disebabkan oleh kesalahan akan diminimalkan. Akhirnya penting untuk dicatat bahwa suatu sistem dapat di desain secara modular, bahkan juga bila implementasinya harus “monolistik”. Ada situasi (misalnya perangkat lunak real time, perangkat lunak embedded) di mana kecepatan dan subrutin, prosedur) tidak dapat diterima. Dalam situasi seperti itu, perangkat lunak dapat dan harus dirancang dengan modularitas sebagai sebuah filosofi yang diprogram tidak kelihatan modular pada saat pertamanya, filosofi harus dijaga, dan program tersebut akan memberikan manfaat sistem modular.
Disini Terdapat beberapa Rangkaian Lengkap Dari Konsep dan Prinsip Design.
- Desain software dan software engineering
- Process desain
- Prinsip desain
- Konsep desain
- Abstraksi, perbaikan, modularity
- Arsitektur software
- Hirarki control
- Partisi struktural
- Struktur data
- Procedur software
- Information yang tersembunyi
- Desain modular yang efektif
- Ketergantungan fungsional, kohesi, penggabungan Desain heuristic untuk modularity efektif Model desain Dokumentasi desain.
Desain Software dan Software Engineering
Desain ->Langkah pertama dalam fase pengembangan untuk prodengineer manapun. Bertindak sebagai pondasi untuk semua software engineering dan pemeliharaan software dengan langkah-langkah yang mengikutinya.
Tujuan seorang perancang adalah menghasilkan suatu model(atau penyajian) dari sebuah entitas yang akan dibangun
Input desain software : Model analisa kebutuhan dan dokumentasi spesifikasi
Output desain software : Model desain dan dokumentasi spesifikasi desain
Desain - menerjemahkan kebutuhan ke model desain lengkap untuk sebuah produk software.
- menyediakan representasi software yang dapat diduga untuk kualitas.
Desain Software
Sejumlah metode desain dapat digunakan untuk menghasilkan desain software:
- Desain data: mentransformasi model domain informasi ke struktur data
- Desain arsitektur: menggambarkan relasi antar elemen struktural utama program
- Desain interface : mendeskripsikan bagaimana software berkomunikasi with user
- Desain prosedur: mentransformasikan elemen structural arsitektur program ke sebuah deskripsi prosedur dari komponen software.
Evolusi desain software:
- Konstruksi program modular[DEN73] dan metode perbaikan top-down[WIR71].
- Pemrograman terstruktur [DAH71, MIL72].
- Perpindahan data flow/data structure ke sebuah defenisi desain[JAC75][WAR74].
- Pendekatan berorientasi object[JAC92][GAM95].
Fitur umum metode desain software:
- Sebuah mekanisme untuk perpindahan sebuah model analisa ke representasi desain
Sebuah notasi untuk merepresentasi komponen fungsional dan interface-nya.
Heuristic untuk perbaikan dan partisi
Panduan untuk assessment kualitas
- Evaluasi “iterasi pertama” dari struktur program untuk mengurangi perangkaian dan meningkatkan kohesi.
- Usahakan meminimalkan struktur dengan fan-out yang tinggi; usahakan untuk melakukan fan-in pada saat kedalaman (depth) bertambah.
- Jagalah supaya lingkup efek dari suatu model ada dalam lingkup control.
- Evaluasi interface modul untuk mengurangi kompleksitas dan redundansi.
- Tetapkan modul-modul yang fungsinya dapat diprediksi, tetapi hindari modul yang terlalu restriktif.
- Usahakan modul-modul “entri kontrol” dengan menghindari “hubungan patalogis”
- Kemaslah software berdasarkan batasan desain dan persyaratan probabilitas.
Proses Desain
Desain software --> sebuah proses iteratif dimana kebutuhan diterjemahkan ke sebauh “blueprint” untuk mengkonstruksi software.
Desain direpresentasikan pada level atas abstraction. Saat iterasi desain terjadi, perbaikan subsequent membawa ke representasi desain pada level abstraksi yang lebih bawah.
Kualitas desain sangat penting. Dua metode digunakan untuk mengecek kualitas:
a) Tinjauan ulang teknis formal, dan b) desain walkthrough
Tiga fitur umum sebuah desain yang baik dari McGlaughlin’s [McG91]:
- Desain harus mengimplementasikan semua kebutuhan(eksplisit/implisit)
- Desain harus dapat dibaca dan dimengerti
- Desain harus menyediakan suatu gambar lengkap software pada aspek aspek data, fungsi dan perilaku.
Kualitas Desain
Untuk mengevaluasi sebuah desain software, sebauh criteris kualitas desain dapat digunakan.
Berikut panduan untuk sebuah desain yang baik:
- Sebuah desain harus A design should exhibit a hierarchical organization about software
- Sebuah desain harus modular berdasarkan pada partisi logical.
Sebuah desain terdiri dari data dan abstraksi prosedural.
Sebuah desain harus membawa ke modul dengan fitur fungsional yang independen.
Sebuah desain harus membawa interface yang sederhana antar modul.
Sebuah desain harus diturunkan menggunakan metode yang dapat berulang.
Proses desain software memacu desain yang baik dalam aplikasi dengan prinsip desain fundamental, metodologi yang sistematik, dan melalui review(pengulangan).
Prinsip Desain
David [DAV95] memaparkan sekumpulan prinsip untuk desain software:
- Proses desain seharusnya tidak bertahan dari “tunnel vision”.
- Desain harus dapat di trace ke model analisa.
- Desain seharusnya tidak menemukan/invent wheel.
- Desain harus “memperkecil jarak intellectual” antara software dan masalah-masalah pada dunia nyata.
- Desain harus mengeluarkan uniformity dan integrasi.
- Desain harus terstruktur untuk mengakomodasi perubahan.
- Desain harus terstruktur untuk mendegradasi secara halus(degrade gently).
- Desain bukan coding.
- Desain harus di-assessed untuk kualitas.
Desain harus diulang untuk meminimalis kesalahan konsep.
Faktor kualitas eksternal: diobservasi oleh user.
Faktor kualitas internal: penting untuk engineer.
Konsep Desain
Abstraksi:
Tiap langkah pada proses software engineering adalah sebuah perbaikan pada tingkatan abstraksi dari solusi software.
- Abstraksi data: Sekumpulan data
- Abstraksi prosedural:
Satu urutan instruksi pada sebuah fungsi spesifik
- Abstraksi kontrol:
Sebuah program mengkontrol mekanisme tanpa menspesifikasikan detail internal.
Refinement(perbaikan): Perbaikan sebenarnya adalah sebuah proses dari elaborasi.
Stepwise dari perbaikan adalah sebuah strategi desain top-down yang dikeluarkan oleh Niklaus [WIR71].
Arsitektur sebuah program dikembangkan dengan sukses memperbaiki
level detail procedural.
Proses perbaikan program analog terhadap proses perbaikan dan partisi yang digunakan selama analisa kebutuhan. Perbedaan utama berada pada level detail implementasi, disamping pendekatannya.
Abstraksi dan perbaikan secara komplemen dikonsep.
Abstraksi memungkinkan seorang desainer untuk menspesifikasi prosedur dan data w/o detail.
Perbaikan membantu desainer untuk me-reveal detail low-level.
Konsep Desain - Modularity
Konsep modularity telah dipakai selama hampir empat dekade.
Software dibagi komponen dengan nama dan alamat yang berbeda, disebut modul.
Meyer [MEY88] mendefenisikan lima kriteria yang memungkinkan kita mengevaluasi sebuah metode desain dengan bergantung kepada kemampuannya mendefenisikanfive sebuah sistem modular efektif:
Modular decomposability: sebuah metode desain menyediakan sebuah mekanisme sistematik untuk men- decompose atau membagi masalah ke sub-masalahà mengurangi kompleksitas dan mendapatkan modularity
Modular composability: sebuah metode desain memungkinkan komponen desain yang telah ada dirakit ke sebuah sistem baru.
Modular understandability: sebuah modul dapat dimengerti sebagai sebuah unit yang berdiri sendiri dan akan lebih mudah membangun dan mengubahnya.
Modular continuity: perubahan kecil terhadap kebutuhan sistem menghasilkan perubahan pada tiap modul, dibanding perubahan system-wide.
Modular protection: sebuah kondisi aberrant terjadi dalam sebuah modul dan efeknya di-constrain
dalam modul.
Arsitektur Software
Arsitektur software adalah struktue hirarki dari komponen program components dan interaksinya.
Shaw dan Garlan [SHA95a] menggambarkan sekumpulan properti desain arsitektur:
Properti structural : Desain arsitektur mendefenisikan komponen sistem dan interaksinya.
Properti extra-functional : Desain arsitektur harus meng-address bagaimana arsitektur desain menerima kebutuhan untuk performance, kapasitas, ketersediaan(reliability), adaptability, keamanan.
Kumpulan sistem yang berhubungan:
desain arsitektur harus menggambar pola yang dapat diulang pada desain dengan sistem yang sama.
Metode desain arsitektural yang berbeda:
Model structural: merepresentasikan arsitektur sebagai sebuah koleksi terorganisir dari komponen
Model framework: meningkatkan level desain abstraksi dengan mengidentifikasi secara berulang
framework desain arsitektur(pola-pola)
Model dinamis: meng-address aspek-aspek perilaku arsitektur program
Model prosess: fokus pada desain bisnis atau proses teknis
Model functional: dapat digunakan untuk merepresentasikan hierarki fungsional sebuah sistem
Partisi Structural
Struktur program harus dipartisi secara horizontal dan vertikal. (Gambar 13.4)
(1)Partisi horizontal menggambarkan cabang-cabang yang terbagi dari hierarki modular untuk tiap fungsi program utama.
Cara termudah adalah mempartisi sebuah sistem menjadi:
input, transformasi data(pemrosesan), dan output
Keuntungan dari partisi horizontal:
- mudah untuk diuji, di-maintain, dan extend
- efek yang lebih kecil pada perubahan propagasi atau error propagasi
Kerugian: lebih banyak data dilewatkan melalui interface modul
--> menyulitkan kontrol keseluruhan dari aliran program
(2) Partisi vertical memaparkan kontrol dan work harus terdistribusi top-down dalam struktur program.
Keuntungan: baik pada kesesuain untuk perubahan:
- mudah untuk me-maintain perubahan
- mengurangi pengaruh perubahan dan propagasi.
Desain Modular Efektif
Informasi yang disimpan: Modul-modul seharusnya dispesifikasi dan didesain sehingga detail internal dari modul darus dapat terlihat atau dapat diakses terhadap modul lainnya.
Keuntungan utama: mengurangi pengaruh perubahan pada testing(pengujian) dan maintenance(perawatan).
Independen fungsional: Mendesain modul-modul berdasarkan fitur fungsional independen.
Keuntungan utama: modularity efektif
Cohesion: sebuah ekstensi alami dari konsep informasi yang disimpan sebuah modul dapat menampilkan sejumlah tusk
Sebuah modul cohesive menampilkan sebuha task tunggal dalam sebuah prosedur dengan interaksi kecil dengan lainnya.
Goal: untuk mencapai cohesion yang tinggi untuk modul-modul pada sebuah sistem.
Tipe-tipe yang berbeda dari cohesion:
- coincidentally cohesive: sekumpulan task yang berhubungan satu sama lain secara bebas.
- logically cohesive: koneksi logical antara elemen-elemen pemrosesan
- communication cohesion: data di-share antar elemen-elemen pemrosesan
- procedural cohesion: pemesanan antara elemen-elemen pemrosesan
Desain Modular Efektif
Coupling: (Gambar 13.8)
Suatu ukuran interkoneksi antar modul-modul dalam sebuah struktur program.
Coupling tergantung pada kompleksitas interface antar modul.
Goal: mencoba untuk coupling terendah yang mungkin antar modul.
Coupling yang baik à mengurangi atau mencegah pengaruh perubahan dan efek ripple.
à mengurangi biaya pada perubahan program, testing,
maintenance
Tipe-tipe coupling:
- data coupling: parameter passing atau interaksi data
- control coupling: share logical kontrol yang berhubungan (untuk sebuah data kontrol)
- common coupling: sharing data umum
- content coupling: modul, penggunaan data atau pengontrolan
informasi di-maintain modul lain.
