1. SOFTWARE REUSEProses 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 :KeuntunganKeterangan

Keandalan bertambahKomponen 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 diperkecilJika 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 efektifSpesialis aplikasi tidak melakukan pekerjaan yang sama pada berbagai proyek, tapi mereka dapat mengembangkan komponen-komponen yang dapat dipakai ulang yang mengengkapsulasi pengetahuan mereka.

Pemenuhan standarBeberpa 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 dipercepatMembawa 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 :MasalahKeterangan

Biaya pemeliharaan yang membengkakJika 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 bantuToolset 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 siniBeberapa 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 komponenMemenuhi 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 ulangKomponen 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 ENGINEERINGComponent 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 :Pakai Komponen yang ditemukanCari Komponen ReuseSpesifikasi KomponenRancang Arsitektur Sistem

Gambar 1. Proses Pemakaian UlangPerancang 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 :Perancangan SistemPencarian KomponenPerancangan ArsitekturalModifikasi PersyaratanPencarian KomponenPersyaratan Sistem

Gambar 2. Penggambaran dengan pemakaian ulangPada 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 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.