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.