BAB 5. DESAIN
C. KONSEP DESAIN
Serangkaian konsep desain perangkat lunak fundamental telah berkembang, meskipun tingkat minat pada setiap konsep bervariasi selama bertahun-tahun. Konsep desain membantu perekayasa perangkat lunak untuk menjawab beberapa pertanyaan berikut:
1) Kriteria apa yang dapat digunakan untuk mempartisi perangkat lunak ke dalam komponen-komponen individual?
2) Bagaimana detail struktur data atau fungsi dipisahkan dari suatu representasi konseptual perangkat lunak?
3) Adakah kriteria yang seragam yang menentukan kualitas teknis suatu desain perangkat lunak?
Konsep desain perangkat lunak fundamental memberikan kerangka kerja untuk mendapatkan program yang berfungsi dengan benar.
1. Abstraction
Pada saat kita mempertimbangkan solusi modular terhadap setiap masalah, banyak tingkat abstraksi yang dapat diperoleh. Pada tingkat abstraksi tinggi solusi dinyatakan dalam istilah yang luas. Pada saat kita bergerak pada tingkat abstraksi yang berbeda, kita bekerja untuk membuat abstraksi data dan prosedural. Abstraksi prosedural adalah urutan instruksi yang diberi nama dan mempunyai fungsi tertentu dan terbatas. Contoh abstraksi procedural adalah kada Open pada sebuah pintu. Open mengklasifikasikan urutan panjang dari langkah-langkah procedural (misal berjalan ke pintu, menggapai dan meraih tombol; memutar tombol; mendorong pintu; dsb.). Abstraksi data adalah kumpulan data yang bernama yang menggambarkan objek data.
Sejumlah bahasa pemrograman (seperti Ada, Modula dan CLU) memberikan mekanisme untuk membuat berbagai tipe data abstrak. Abstraksi kontrol adalah bentuk ketiga dari abstraksi yang dipakai dalam desain perangkat lunak. Abstraksi kontrol mengimplementasikan suatu mekanisme kontrol program tanpa menentukan detail-detail internal.
2. Modularity
Konsep modularitas dalam perangkat lunak komputer telah didukung selama hampir empat dekade. Modularitas merupakan konsep dimana perangkat lunak dipecah menjadi beberapa komponen dan diberi nama untuk dipanggil secara terpisah. Modularitas adalah attribute tunggal dari perangkat lunak yang memungkinkan sebuah program untuk dikelola secara intelektual. Perangkat lunak monolitik (yakni program besar yang terdiri dari modul tunggal) tidak dapat dipahami dengan mudah oleh pembaca. Jumlah alur kontrol, cakupan referensi, jumlah variable, dan kompleksitas keseluruhan akan membuat pemahaman menjadi hamper tidak mungkin. Ada beberapa kriteria yang menjadi ciri sistem modular yang efektif:
a) Dekomposisi Modular
Bila metode desain memberikan suatu mekanisme sistematis untuk melakukan dekomposisi terhadap masalah menjadi sub masalah-sub masalah, maka metode dasain akan mengurangi kompleksitas keseluruhan masalah, sehingga dapat mencapai solusi modular efektif.
b) Komposabilitas Modular
Bila suatu metode desain memungkinkan komponen desain (reuseable) yang ada untuk dipasang ke dalam sebuah sistem baru, maka metode desain akan menghasilkan suatu solusi modular yang tidak berulang.
c) Kemampuan Pemahaman Modular
Jika sebuah modul dapat dipahami sebagai unit yang berdiri sendiri (tanpa referensi dan modul lain), maka modul akan lebih mudah dibangun dan diubah. d) 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 perubahan dapat diminimalkan.
e)
Proteksi ModularBila terjadi kondisi yang menyimpang pada modul tersebut, pengaruh dari efek samping yang disebabkan oleh kesalahan akan diminimalkan.
3. Software Architecture
Arsitektur perangkat lunak mencakup struktur keseluruhan perangkat lunak dan cara dimana struktur memberikan integrasi konseptual bagi suatu sistem. Dalam bentuknya yang paling sederhana, arsitektur merupakan struktur hirarki dari komponen program (modul), cara bagaimana komponen tersebut berinteraksi, dan struktur yang digunakan oleh komponen. Secara lebih luas komponen dapat digeneralisir untuk mewakili elemen-elemen sistem mayor dan interaksi mereka.
Tujuan desain perangkat lunak adalah untuk mendapatkan gambaran arsitektural sebuah sistem. Gambaran tersebut berfungsi sebagai kerangka kerja yang dari sana aktivitas desain yang lebih detail dilakukan. Serangkaian pola arsitektural memungkinkan perekayasa perangkat lunak untuk menggunakan kembali konsep tingkat desain.
a. Control Hierarchy
Hirarki kontrol, disebut juga struktur program mewakili organisasi komponen (modul) serta mengimplementasikan suatu hirarki kontrol. Hirarki kontrol tidak mengimplementasikan aspek procedural dari perangkat lunak, seperti urutan proses, urutan kejadian, keputusan atau pengulangan.
Hirarki kontrol juga mewakili dua karateristik yang berbeda dari arsitektur perangkat lunak yaitu visibilitas dan konektivitas. Visibilitas menunjuk kepada serangkaian komponen yang dapat diminta atau dipakai sebagai daa oleh komponen yang lain. Sedangkan konektivitas menandai serangkain komponen yang diminta secara tidak langsung atau digunakan sebagai data oleh sebuah modul yang ditetapkan. Sebagai contoh sebuah modul yang secara langsung menyebabkan modul lain memulai eksekusi akan disambungkan dengan modul tersebut.
b. Structural Partitioning
Struktur program harus dipartisi baik secara horizontal maupun struktural/vertikal. Partisi arsitektural secara horizontal memberikan keuntungan nyata, yaitu:
a) Menghasilkan perangkat lunak yang mudah diuji. b) Perangkat lunak mudah dipelihara.
c) Efek samping buruk yang dihasilkan perangkat lunak lebih sedikit.
d)
Menghasilkan perangkat lunak yang mudah diperluas.Gambar 5.1 Partisi Horisontal
Partisi vertical seperti gambar 5.2 yang sering disebut pemfaktoran menyatakan bahwa control/pembuat keputusan (decision making modules) dan kerja harus didistribusikan secara top-down dalam arsitektur program. Modul tingkat puncak harus melakukan fungsi-fungsi kontrol dan melakukan sedikit kerja pemrosesan aktual. Modul-modul yang dalam arsitektur berada di bawah harus menjadi para pekerjanya yaiut melakukan tugas input, komputasi dan output.
Sifat perubahan dalam arsitektur program membenarkan kebutuhan akan partisi vertikal. Perubahan pada modul kontrol (tinggi dalam arsitektural) akan memiliki probabilitas penyebaran efek samping yang lebih tinggi ke modul yang menjadi sub ordinatnya. Perubahan pada modul pekerja (worker modules) yang memiliki tingkat rendah dalam arsitektur, lebih kecil kemungkinannya untuk menyebabkan penyebaran efek samping. Secara umum perubahan program komputer berada di seputar perubahan input, komputasi dan transformasi serta output.
c. Data Structure
Struktur data adalah representasi dari hubungan logis antara elemen-elemen data individual. Karena struktur informasi akan secara bervariasi mempengaruhi desain prosedural akhir, maka struktur data sama pentingnya dengan struktur program pada representasi arstitektur perangkat lunak. Struktur data menentukan organisasi, metode akses, tingkat hubungan dan alternatif pemrosesan untuk informasi. Ada sejumlah struktur data klasik yang membentuk blok bangunan bagi struktur yang lebih canggih. Struktur data yang lain digabungkan atau dikonstruksi dengan menggunakan struktur data fundamental seperti yang telah dijelaskan.
Penting untuk dicatat bahwa struktur data seperti struktur program dapat direpresentasikan pada tingkat abstraksi yang berbeda. Contohnya stack adalah model konseptual dari suatu struktur data yang dapat diimplementasikan sebagai vendor atau sebuah
linked list.
d. Software Procedure
Struktur program membatasi hirarki kontrol tanpa melihat urutan pemrosesan data keputusan. Prosedur perangkat lunak berfokus pada detail-detail pemrosesan dari masing-masing modul secara terpisah. Prosedur harus memberikan spesifikasi yang teliti terhadap pemrosesan, mencakup urutan event, poin-poin keputusan nyata, operasi repetitive dan bahkan organisasi/struktur data.
Ada hubungan antara struktur dan prosedur. Pemrosesan yang diindikasikan bagi masing-masing modul harus mencakup referensi bagi semua sub ordinat modul yang sedang digambarkan, yaitu representasi procedural dari perangkat lunak yang dilapiskan seperti pada gambar 5.3.
Gambar 5.3 Prosedur dibuat Berlapis
e. Information Hiding
Konsep modularitas membawa setiap desainer perangkat lunak ke suatau pertanyaan mendasar yaitu bagaimana mendekomposisi suatu solusi perangkat lunak untuk mendapatkan serangkaian modul terbaik. Prinsip penyembunyian informasi menyatakan bahwa modul ditandai dengan keputusan desain yang (masing-masing) tersembunyi dari semua desain lain. Dengan kata lain modul seharusnya ditentukan dan didesain sehingga informasi (prosedur dan data) yang diisikan pada sebuah modul tidak dapat diakses ke modul lain yang tidak memiliki kepentingan terhadap informasi tersebut.
Penyembunyian informasi memberikan bukti bahwa modularitas efektif dapat dicapai dengan menetapkan serangkaian modul yang independen yang berkomunikasi satu dengan yang lainnya dimana hanya informasi itu yang diperlukan untuk mencapai fungsi perangkat lunak. Penggunaan penyembunyian informasi sebagai suatu criteria desain untuk sistem modular memberikan keuntungan terbesarnya pada saat dibutuhkan modifikasi selama pengujian dan sesudahnya yaitu selama pemeliharaan perangkat lunak. Karena sebagaian besar data dan prosedur disembunyikan dari bagian perangkat lunak lain, maka kesalahan kecil yang
terjadi selama modifikasi punya kemungkinan lebih kecil untuk menyebarke lokasi lain dalam perangkat lunak.