1.

SOFTWARE REUSE
Proses perancangan pada sebagian besar disiplin ilmu didasarkan pada pemakaian ulang
komponen. Insinyur mesin dan insinyur elektro tidak menspesifikasikan suatu desain di mana
setiap komponen harus khusus diproduksi. Mereka mendasarkan desain pada komponen yang
telah dicoba dan diuji pada system lain. Komponen-komponen ini tidak hanya berupa komponen
kecil seperti roda atau katup tetapi mencakup subsistem utama seperti mesin, kondensor, atau
turbin.
Sekarang telah diterima secara luas bahwa kita membutuhkan pendekatan yang dapat
dibandingkan terhadap pengembangan perangkat lunak. Perangkat lunak harus dianggap sebagai
suatu asset dan pemakaian ulang asset ini sangat penting untuk menaikkan pengembalian dari
biaya pengembangannya. Permintaan untuk produksi perangkat lunak dan biaya pemeliharaan
yang rendah, penyerahan system yang cepat dan kualitas yang lebih baik, hanya dapat dipenuhi
oleh pemakaian ulang perangkat lunak yang luas dan sistematis.
Pemakaian ulang perangkat lunak harus diperhitungkan pada saat perancangan perangkat lunak
atau proses rekayasa persyaratan. Pemakaian ulang yang oportunistik mungkin dilakukan pada
saat pemrograman, ketika ditemukan komponen yang memenuhi suatu persyaratan. Namun
demikian, pemakaian ulang yang sistematik menuntut proses perancangan yang
mempertimbangkan bagaimana desain yang sudah ada dapat dipakai ulang, dan secara eksplisit
membuat desain berdasarkan komponen perangkat lunak yang sudah ada.
Rekayasa perangkat lunak yang berbasis pemakaian ulang merupakan pendekatan terhadap
pengembangan yang mencoba memaksimalkan pemakaian ulang perangkat lunak yang ada. Unit
perangkat lunak yang dipakai ulang bisa berukuran sangat berbeda. Sebagai contoh :
1. Pemakaian ulang system aplikasi.
Seluruh system aplikasi dapat dipakai ulang dengan menggabungkannya tanpa perubahan
dengan system lain ( pemakaian ulang produk COTS ) atau dengan mengembangkan
kerabat aplikasi yang dapat berjalan pada platform yang berbeda atau dapat dikhususkan
untuk keperluan pelanggan tertentu.
2. Pemakaian ulang komponen.
Komponen dari suatu aplikasi yang ukurannya berkisar dari subsistem sampai satu objek
tunggal dapat dipakai ulang. Sebagai contoh, system pengenal pola yang dikembangkan
sebagai suatu bagian system pengolahan teks dapai dipakai ulang pada system
manajemen basis data.
3. Pemakaian ulang fungsi.
Komponen ulang yang mengimplementasi satu fungsi, seperti fungsi matematika dapat
dipakai ulang. Bentuk pemakaian ulang ini berdasarkan pada library standar atau yang
umum dipakai selama ini.
Pemakaian ulang system aplikasi telah dipraktekkan secara luas selama beberapa tahun pada saat
perusahaan-perusahaan perangkat lunak mengimplementasikan system mereka pada berbagai
mesin dan menyesuaikannya untuk berbagai lingkungan. Pemakaian ulang fungsi juga
dimapankan melalui library standar dari fungsi-fungsi yang dapat dipakai ulang sebagai library
grafik dan matematika. Namun demikian, walaupun ada minat terhadap pemakaian ulang
komponen sejak awal tahun 1980-an, baru beberapa tahun belakangan ini cara ini diterima
sebagai pendekatan yang praktis terhadap pengembangan system perangkat lunak.
Keuntungan yang jelas dari pemakaian ulang perangkat lunak adalah diperkecilnya biaya
pengembangan secara keseluruhan. Komponen-komponen perangkat lunak yang harus
dispesifikasi, dirancang, diimplementasi, dan divalidasi menjadi berkurang. Namun demikian,
reduksi biaya hanya merupakan salah satu keuntungan potensial dari pemakaian ulang. Ada
sejumlah keuntungan lain dari pemakaian ulang asset perangkat lunak, sebagaimana ditunjukkan
pada table di bawah ini :
Keuntungan Keterangan
Keandalan bertambah Komponen yang dipakai ulang, yang telah
digunakan pada system yang telah berjalan
seharusnya lebih dapat diandalkan daripada
komponen baru. Komponen ini telah dicoba
dan diuji pada berbagai lingkungan. Kesalahan
perancangan dan implementasi ditemukan dan
dihilangkan pada pemakaian awal komponen
tersebut sehingga memperkecil jumlah
kegagalan pada pemakaian ulang.
Resiko proses diperkecil Jika suatu komponen telah ada, ketidakpastian
biaya pemakaian ulang menjadi lebih kecil
daripada biaya pengembangan. Ini merupakan
factor penting untuk manajemen proyek karena
memperkecil ketidakpastian dalam estimasi
biaya proyek. Hal ini terutama berlaku ketika
komponen-komponen yang relative besar
seperti subsistem dipakai ulang.
Pemakaian spesialis yang efektif Spesialis aplikasi tidak melakukan pekerjaan
yang sama pada berbagai proyek, tapi mereka
dapat mengembangkan komponen-komponen
yang dapat dipakai ulang yang
mengengkapsulasi pengetahuan mereka.
Pemenuhan standar Beberpa standar seperti standar interface dapat
diimplementasi sebagai satu set komponen
standar. Sebagai contoh, komponen yang dapat
dipakai ulang dapat dikembangkan untuk
implemantasi menu sebagai interface user.
Semua aplikasi menyediakan format menu
yang sama kepada user. Pemakaian interface
user standar memperbaiki keandalan karena
kemungkinan user melakukan kesalahan ketika
dihadapkan dengan interface yang sudah
mereka kenal menjadi lebih kecil.
Pengembangan yang dipercepat Membawa suatu system ke pasar secepat
mungkin seringkali lebih penting dari biaya
pengembangan secara keselurahan. Pemakaian
ulang komponen mempercepat produksi karena
waktu pengembangan dan waktu validasi akan
dipersingkat.

Ada 3 persyaratan kritis perancangan dan pengembangan perangkat lunak dengan pemakaian
ulang :
1. Komponen yang dapat dipakai ulang dan sesuai harus mungkin ditemukan. Organisasi
membutuhkan dasar berupa komponen yang dapat dipakai ulang yang terdapat pada
katalog dan dokumen yang disusun dengan baik. Jika memang ada, komponen-komponen
pada katalog ini harus mudah ditemukan.
2. Pemakaian ulang komponen harus pasti bahwa komponen-komponen tersebut akan
bekerja sebagaimana dispesifikasi dan akan handal. Idealnya, semua komponen pada
katalog organisasi harus disertifikasi untuk meyakinkan bahwa komponen-komponen
tersebut telah memenuhi standar kualitas tertentu.
3. Komponen tersebut harus memiliki dokumentasi yang berhubungan untuk membantu
pemakai ulang memahaminya dan mengadaptasinya ke aplikasi yang baru. Dokumentasi
harus mencakup informasi mengenai di mana komponen-komponen ini telah dipakai
ulang dan jika ada, masalah-masalah pemakaian ulang yang telah ditemukan.
Kebehasilan pemakaian Visula Basic dan Visual C++ dengan komponen-komponen dan Java
dengan JavaBeans telah menunjukkan nilai pemakaian ulang. Rekayasa perangkat lunak berbasis
komponen telah diterima luas sebagai pendekatan yang sangat efektif teerhadap pengembangan
perangkat lunak.
Namun demikian, tidak sedikit masalah yang berhubungan dengan pemakaian ulang. Untuk lebih
jelasnya dapat dilihat pada table di bawah ini :
Masalah Keterangan
Biaya pemeliharaan yang membengkak Jika sorce-code komponen tidak tersedia maka
biaya pemeliharaan dapat bertambah besar
karena elemen system yang diapaki ulang bisa
makin tidak kompatibel dengan perubahan
system.
Tidak adanya dukungan alat bantu Toolset CASE tidak mendukung
pengembangan dengan pemakaian ulang.
Integrasi alat bantu ini dengan system library
komponen mungkin sulit atau bahkan tidak
mungkin. Proses perangkat lunak yang
diasumsikan ini tidak memperhitungkan
pemakaian ulang.
Sindrom tidak dibuat di sini Beberapa perekayasa perangkat lunak kadang-
kadang lebih suka menulis kembali komponen
karena mereka percaya bahwa mereka dapat
membuat suatu komponen yang dipakai ulang.
Hal ini sebagian disebabkan oleh fakta bahwa
menulis perangkat lunak yang orisinil tampak
lebih menantang ketimbang memakai ulang
perangkat lunak orang lain.
Mempertahankan library komponen Memenuhi library komponen dan menjamin
bahwa pengembang perangkat lunak dapat
memakai library ini mungkin akan mahal.
Teknik terbaru untuk klasifikasi katalog dan
mengambil komponen perangkat lunak belum
matang.
Menemukan dan mengadaptasi komponen
yang dapat dipakai ulang
Komponen perangkat lunak harus ditemukan
pada suatu library, dipahami, dan kadangkala
diadaptasi untuk bekerja pada lingkungan yang
baru. Perekayasa harus cukup yakin dapat
menemukan komponen di library sebelum
secara rutin memasukkan pencarian komponen
sebagai bagian dari proses pengembangan
normal mereka.


2. COMPONENT BASED SOFTWARE ENGINEERING
Component Based Software Engineering atau pengembangan berbasis komponen muncul pada
akhir tahun 1990-an sebagai pendekatan berbasis pemakaian ulang terhadap pengembangan
system perangkat lunak. Motivasinya adalah kefrustrasian bahwa pengembangan berorientasi
objek tidak berkembang menjadi pemakaian ulang yang ekstensif sebagaimana diperkirakan
pada awalnya. Kelas objek tunggal terlalu rinci dan spesifik dan harus dibatasi dengan aplikasi
pada waktu kompilasi atau ketika system di-link. Dibutuhkan pengetahuan yang detil mengenai
kelas ini untuk dapat menggunakannya, dan ini biasanya berarti bahwa source code harus
tersedia. Ini menimbulkan masalah yang sulit untuk memasarkan komponen, walaupun pada
awalnya diramalkan dengan optimis, pasar yang signifikan untuk objek individu tidak pernah
berkembang.
Komponen lebih abstrak dari kelas objek dan dapat dianggap sebagai penyedia layanan yang
berdiri sendiri. Ketika system membutuhkan layanan, system memanggil komponen untuk
menyediakan layanan tersebut tanpa peduli di mana komponen tersebut berjalan atau bahasa
pemrograman yang dipakai untuk mengembangkannya. Sebagai contoh, suatu komponen yang
sangat sederhana bisa berupa satu fungsi matematika untuk menghitung akar kuadrat suatu
bilangan. Ketika program membutuhkan perhitungan akar kuadrat, program memanggil
komponen tersebut untuk menyediakannya. Di pihak lain, system yang perlu melakukan
perhitungan matematika dapat memanggil komponen spreadsheet yang menyediakan layanan
kalkulasi.
Penggambaran suatu komponen sebagai penyedia layanan menekankan dua karakteristik kritis
dari komponen yang dapat dipakai ulang :
1. Komponen merupakan entitas yang dapat dieksekusi dan independen. Source code tidak
tersedia sehingga komponen tidak dikompilasi dengan komponen system lain.
2. Komponen mengeluarkan interface mereka dan semua interaksi melalui interface
tersebut. Interface komponen dinyatakan dalam operasi yang diparameterisasi dan status
internalnya tidak pernah diperlihatkan.
Komponen didefinisikan oleh interfacenya dan dalam kasus yang paling diumum dianggap
memiliki dua interface yang berhubungan yakni :
1. Interface provides yaitu interface yang mendefinisikan layanan yang disediakan oleh
komponen tersebut.
2. Interface requires yaitu interface yang menspesifikasi layanan apa yang harus tersedia
dari system yang memakai komponen itu. Jika ini tidak disediakan, maka komponen
tidak akan bekerja.
Komponen-komponen bisa diakses pada tingkat abstraksi yang berbeda-beda. Mayer (1999)
mengidentifikasi lima tingkat anstraksi :
1. Abstraksi fungsional : Komponen mengimplementasi satu fungsi, misalnya fungsi
matematika. Pada intinya, interface provides merupakan fungsi itu sendiri.
2. Pengelompokan kasula : Komponen merupakan sekumpulan entitas yang berhubungan
longgar (loosely related) yang mungkin berupa deklarasi data, fungsi, dan sebagainya.
Interface provides terdiri dari nama semua entitas pada pengelompokan tersebut.
3. Abstraksi data : Komponen merepresentasikan abstraksi data atau kelas perangkat lunak
bahasa berorientasi objek. Interface provides terdiri dari operasi untuk membuat,
memodifikasi, dan mengakses abstraksi data.
4. Abstraksi cluster : Komponen merupakan sekumpulan kelas yang berhubungan yang
bekerja sama. Kelas-kelas ini kadang-kadang dinamakan kerangka kerja. Interface
provides merupakan komposisi semua interface provides dari objek-objek yang
membangun kerangka kerja tersebut.
5. Abstraksi system : Komponen merupakan system yang sepenuhnya berdiri sendiri.
Pemakaian ulang abstraksi tingkat system kadangkala disebut pemakaian ulang produk
COTS. Interface provides adalah apa yang disebut API (Application Progamming
Interface) yang didefinisikan untuk memungkinkan program mengakses command dan
operasi system.
Pengembangan berorientasi komponen dapat diintegrasikan ke dalam proses pengembangan
system dengan menggunakan kegiatan pemakaian ulang yang spesifik sebagaimana ditunjukkan
pada gambar di bawah ini :


Rancang
Arsitektur Sistem
Spesifikasi
Komponen
Cari Komponen
Reuse
Pakai Komponen
yang ditemukan
Gambar 1. Proses Pemakaian Ulang
Perancang system menyelesaikan perancangan tingkat tinggi dan spesifikasi komponen desain
tersebut. Spesifikasi ini digunakan untuk menemukan komponen yang akan dipakai ulang.
Spesifikasi ini mungkin dimasukkan pada tingkat arsitektural atau pada tingkat perancangan
yang lebih rinci.
Walaupun pendekatan ini dapat menghasilkan pemakaian ulang yang signifikan, cara ini sangat
kontras dengan pendekatan yang dipakai pada disiplin rekayasa lain, di mana kemampuan
pemakaian ulang mendorong proses perancangan. Alih-alih merancang kemudian mencari
komponen yang dapat dipakai ulang, para perekayasa lebih dahulu mencari komponen yang
dapat dipakai ulang. Mereka mendasarkan desain mereka pada komponen yang tersedia sperti
pada gambar di bawah ini :







Gambar 2. Penggambaran dengan pemakaian ulang
Pada pengembangan yang didorong oleh pemakaian ulang, persyaratan system dimodifikasi
menurut komponen pemakaian ulang (reusable) yang tersedia. Desain juga didasarkan atas
komponen-komponen yang tersedia itu. Tentu saja ini berarti bahwa mungkin saja harus terjadi
kompromi persyaratan. Desain mungkin kurang efisien dari desain khusus. Namun demikian,
biaya pengembangan yg lebih kecil, pengiriman system yang kebih cepat, dan keandalan system
yang bertambah seharusnya dapat mengkompensasi hal ini.
Proses implementasi system dengan menggunakan komponen biasanya merupakan proses
pembuatan prototype atau proses pengembangan incremental. Bahasa pemrograman standar
Perancangan
Arsitektural
Persyaratan
Sistem
Pencarian
Komponen
Pencarian
Komponen
Perancangan
Sistem
Modifikasi
Persyaratan
seperti Java dapat digunakan dengan komponen pada library yang direferensi dari program.
Alternatifnya ( dan lebih umum ) digunakan bahasa scripting yang khusus dirancang untuk
integrasi komponen yang dapat dipakai ulang untuk mendukung pengembangan program yang
cepat.
Mungkin kesulitan utama dalam pengembangan berbasis komponen adalah masalah
pemeliharaan dan evolusinya. Biasanya source code komponen tidak tersedia dan dengan
berubahnya persyaratan aplikasi tidak mungkin bagi kita untuk mengubah komponen demi
merefleksikan persyaratan-persyaratan ini. Pilihan ini mengubah persyaratan pada tahap ini,
untuk menyesuaikan dengan komponen yang tersedia, biasanya tidak mungkin dilakukan karena
aplikasi telah dipakai. Dengan demikian, diperlukan pekerjaan tambahan untuk memakai ulang
komponen dan dengan berlalunya waktu hal ini mengakibatkan biaya pemeliharaan yang
bertambah. Namun demikian, dengan kita mengetahui bahwa pengembangan berbasis komponen
memungkinkan pengiriman perangkat lunak yang lebih cepat, organisasi mungkin berkeinginan
untuk menerima biaya dengan jangka yang lebih panjang ini.