DEFINISI SOFTWARE REUSE

DEFINISI SOFTWARE REUSE

Software Reuse adalah proses menciptakan sistem perangkat lunak

dari perangkat lunak yang sudah ada (tidak membangun sistem

perangkat lunak dari awal). Dengan kata lain software reuse

adalah integrasi dan penggunaan aset perangkat lunak dari sebuah

sistem yang telah dikembangkan sebelumnya.

JENIS SOFTWARE REUSE

a. Oportunistik Reuse - Memulai sebuah proyek dengan menggunakan

kembali komponen yang sudah ada.

Oportunistik Reuse dapat dikategorikan lebih lanjut :

Internal reuse - Sebuah tim me-reuses komponen sendiri. Ini

mungkin sebagai keputusan bisnis, karena tim mungkin ingin

mengontrol sebuah komponen penting untuk proyek tertentu.

External reuse - Sebuah tim mungkin memilih untuk menggunakan

lisensi komponen dari pihak ketiga.

b. Planning Reuse - Sebuah tim akan mendesain komponen strategis

sehingga dapat digunakan kembali dalam proyek-proyek di masa

depan.

UNIT SOFTWARE REUSE

Unit perangkat lunak yang dipakai ulang adalah sebagai berikut :

1. Pemakaian ulang sistem aplikasi.

Seluruh sistem aplikasi dapat dipakai ulang dengan

menggabungkannya tanpa perubahan dengan sistem lain

atau dengan mengembangkan 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, sistem pengenal pola yang

dikembangkan sebagai suatu bagian sistem 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.

PERSYARATAN SOFTWARE REUSE

Ada 3 persyaratan kritis dalam 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.

KEUNTUNGAN SOFTWARE REUSE

Biaya pengembangan lebih kecil

Keandalan bertambah

Resiko proses diperkecil

Pemakaian spesialis yang efektif

Pemenuhan standar

Pengembangan yang dipercepat

MASALAH YANG TERJADI PADA SOFTWARE REUSE

Biaya pemeliharaan yang membengkak

Tidak adanya dukungan alat bantu

Sindrom tidak dibuat di sini ( Peng-codingan ulang )

Mempertahankan library komponen

Menemukan dan mengadaptasi komponen yang dapat dipakai ulang

CBSE

Pengertian Komponen

a. Menurut Szyperski:

Sebuah komponen perangkat lunak adalah unit komposisi dengan

antarmuka kontrak yang ditentukan dan konteks eksplisit hanya

dependensi. Sebuah komponen perangkat lunak dapat digunakan

secara independen dan tunduk pada komposisi oleh pihak ketiga.

b. Councill dan Heinmann:

Sebuah komponen perangkat lunak adalah elemen software yang

sesuai dengan model komponen dan dapat mandiri digunakan dan

terdiri tanpa modifikasi sesuai dengan standar komposisi.

Karakteristik Komponen

Karakteristik komponen antara lain sebagai berikut :

a. Standarisasi : Setelah model komponen standar

b. Independent : Dapat digunakan tanpa Adapators

c. Composable : Interaksi eksternal menggunakan antarmuka

publik

d. Deployable : Stand-alone entitas

e. Didokumentasikan : Dokumentasi lengkap

Model Komponen

Model Komponen adalah definisi standar untuk implementasi komponen, dokumentasi dan penyebaran. Model komponen menentukan bagaimana antarmuka harus didefinisikan dan unsur-unsur yang harus dimasukkan dalam definisi antarmuka. Komponen adalah sebuahbagian yg dapat tergantikan selama masih merealisasikan interface2 yg sama. Interface pada komponen hanya menjelaskan layanan yg disediakan oleh komponen tersebut, bukan implementasinya. Implementasi fisik komponen tersembunyi bagi para penggunanya karena komponen hanya dapat diakses oleh interfacenya.

Komposisi Komponen

Komposisi melibatkan komponen satu sama lain dengan

infrastruktur komponen. Jenis komposisi adalah sebagai berikut

:

a. Komposisi Sequential : dimana komponen dijalankan

secara berurutan. Hal ini melibatkan antarmuka yang

disediakan oleh masing-masing komponen.

b. Komposisi Hirarkis : dimana salah satu komponen

panggilan pada layanan lain. Hal ini menyediakan

antarmuka satu komponen dan antarmuka yang lain.

c. Komposisi Aditif : dimana interface dari dua komponen

diletakkan bersama-sama untuk menciptakan komponen baru.

Adaptor Komponen

Mengatasi masalah ketidakcocokan komponen dengan

mendamaikan antarmuka dari komponen yang terdiri. Berbagai

jenis adaptor yang diperlukan tergantung pada jenis komposisi.

Sebuah addressfinder dan komponen mapper dapat terdiri dari

adaptor yang menempatkan kode pos dari alamat dan melewati ini

untuk komponen mapper.

Identifikasi Komponen

a. Trust : Anda harus dapat mempercayai pemasok komponen.

Paling-paling, komponen yang tidak terpercaya tidak

dapat beroperasi seperti yang diiklankan; paling buruk,

dapat melanggar keamanan Anda.

b. Requirements : Kelompok yang berbeda dari komponen akan

memenuhi kebutuhan yang berbeda.

c. Validation : Komponen spesifikasi mungkin tidak cukup

rinci untuk memungkinkan tes komprehensif untuk

dikembangkan.

ABSTRAKSI KOMPONEN

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.

SPESIFIKASI KOMPONEN

Pengembangan berorientasi komponen dapat diintegrasikan ke dalam

proses pengembangan system dengan menggunakan kegiatan pemakaian

ulang komponen yang spesifik sebagaimana ditunjukkan pada gambar

di bawah ini

Spesifikasi ini digunakan untuk menemukan komponen yang akan

dipakai ulang.Spesifikasi ini mungkin dimasukkan pada tingkat

arsitektural atau pada tingkat perancangan yang lebih rinci

SEJARAH CBSE

Pada konferensi NATO tahun 1968 tentang rekayasa perangkat lunak,

Garmish mencetuskan ide yang bertitel Mass Produced Software

Components yang merupakan cikal bakal lahirnya sebuah paradigma

baru dalam hal rekayasa perangkat lunak. Douglas McIlroy kemudian

mencetuskan ide bahwa software seharusnya dibangun dari komponen-

komponen. Kemudian konsep ini dikembangkan lagi oleh Brad Cox

dari Stepstone dengan Software IC-nya. Di awal 1990-an, IBM

memimpin sebuah proyek dengan nama System Object Model (SOM) yang

kemudian ditiru oleh Microsoft melalui OLE dan COM. Konsep ini

berkembang lebih lanjut hingga dikenal luas dengan istilah

Component-based software engineering (CBSE).

PENGERTIAN CBSEMenurut Pressman, CBSE adalah proses yang menekankan pada perancangan dan pembangunan software dengan menggunakan komponen software yang sudah ada.

Menurut Clemens Szyperski, Pengembangan perangkat lunak berbasis komponen merupakan sebuah model pengembangan yang didasari oleh model Object-Oriented yg mengalami pergeseran paradigm dalam dunia pengembangan perangkat lunak. Pergeseran tersebut adalah perubahan dari sebuah sistem yang dibangun secara monolitik, single platform, dan sistem yang selalu dibuat dari awal (built from scratch) menjadi sebuah komponen yang siap pakai, platform independent yang

memungkinkan adanya komunikasi antar object dan tidak perlu selalu dibuat dari awal. Secara singkat, pengembangan perangkat lunak berbasis komponen ini sangat memperhatikan aspek reusability dari sebuah komponen. Tingkat reusability yang tinggi menjadi syarat mutlakuntuk membuat sebuah komponen.

TUJUAN CBSE

Tujuan dari pengembangan perangkat lunak berbasis komponen ini adalah untuk mengembangkan sebuah sistem yang besar dengan menggabungkan komponen-komponen yang telah dikembangkan sebelumnya sehingga dapat mengurangi waktu dan biaya dalam pengembangan suatu perangkat lunak.

Untuk membuat komponen software yang reusable secara efektif, maka komponen harus :

a. Didokumentasikan secara lengkap

b. Testing secara menyeluruh

c. Check validasi dengan beragam inputan.

d. Menerima feedback error yang berguna

e. Dibangun dengan hati-hati sebab penggunaannya tidak kasat mata.

f. Mekanisme kompensasi yang menguntungkan untuk developer.

PROSES CBSE

Menurut Ivica, Stig, dan Michael dalam jurnal yang berjudul “Component-based Development Process and Component Life Cycle”, alur pengembanganmodel proses Component-based software engineering dapat dilihat padagambar di bawah ini

Penjelasan tahapan model CBSE pada gambar di atas adalah sebagaiberikut:

1) Difinisi Kebutuhan sistem

Model proses CBSE ini dimulai dari tahap definisi dan spesifikasikebutuhan sistem seperti model proses lainnya. Pada model pengembanganperangkat lunak noncomponent-based proses akan diteruskan pada tahapperancangan unit, implementasiunit dan pengujian unit yang dijelaskanpada kotak dengan warna arsiran pada Gambar. Pada tahap ini salah satukegiatan yang penting adalah untuk menganalisis kemungkinan mewujudkansolusi yang memenuhi kebutuhan sistem. Pendekatan ini menyiratkanbahwa perlu untuk menganalisis apakah persyaratan ini dapat dipenuhioleh komponen yang tersedia. Karena tidak mungkin bahwa komponen yangsesuai dapat selalu ditemukan.

2) Perancangan Sistem

Seperti dengan fase definisi kebutuhan sistem, perancangan sistemsangat terkait dengan ketersediaan komponen. Model komponen tertentumembutuhkan arsitektur framework tertentu dan aplikasi sistem tertentu

harus menggunakan framework tersebut juga. Untuk alasan ini prosesperancangan erat terhubung pada ketersediaan komponen. Pada tahappencarian komponen harus benar-benar dilihat dari perancangan sistemitu sendiri, karena dalam suatu repository terdapat banyak komponenyang tidak perlu untuk dipilih. Maka dalam pencarian komponen harusdilakukan proses evaluasi supaya komponen yang dipilih sesuai dengankebutuhan sistem. Untuk mengetahui apakah sebuah komponen sesuaidengan definisi kebutuhan dan perancangan sistem dapat dilihat dariinterface masing-masing komponen. Suatu komponen yang tersedia dalamrepository biasanya sudah teruji dan dapat diadopsi sebelum dapatdiintegrasikan dengan sistem yang lain.

3) Implementasi dan Pengujian Sistem

Pada implementasi sistem meliputi proses integrasi antarainfrasktuktur komponen standar dalam suatu framework dan aplikasiberbasis komponen itu sendiri. Untuk dapat mengintegrasikan antarakomponen dari standar framework dengan aplikasi berbasis komponenyaitu dengan cara melakukan konfigurasi sesuai dengan peraturan yangada pada framework tersebut.

PROSES LAIN CBSE

DomainAnalysis

SoftwareArchitectureDevelopment

ReusableArtifact

Development

Domain Engineering

Domainmodel

StructuralModel

RepositoryReusableArtifacts/

Components

Software Engineering

UserRequirements

SystemAnalysis

Specification&

DesignConstruction

SystemSpec

Analysis& DesignModels

ApplicationSoftware

Keterangan gambar :

a. Domain engineering menciptakan model domain bagi aplikasi

yang akan digunakan untuk menganalisis kebutuhan pengguna.

Identifikasi, pembangunan, pengelompokan dan pengalokasikan

komponen-komponen software supaya bisa digunakan pada sistem

yang ada dan yang akan datang.

b. Software engineering (component-based development) melakukan

analisis terhadap domain model yang sudah ditetapkan

kemudian menentukan spesifikasi dan merancang berdasarkan

model struktur dan spesifikasi sistem, kemudian melakukan

pembangunan software dengan menggunakan komponen-komponen

yang sudah ditetapkan berdasarkan analisis dan rancangan

yang dihasilkan sebelumnya hingga akhirnya menghasilkan

software.

PRINSIP CBSE

Seperti dikutip oleh Herri Setiawan dan Edi Winarko, menurut I

Kaur (2009) CBSE umumnya mewujudkan prinsip-prinsip pengembangan

perangkat lunak fundamental berikut:

a. Independent Software Development, yaitu sistem perangkat lunak

besar yang memisahkan pengembang dan pengguna komponen

melalui abstrak dan spesifikasi implementasi-netral

antarmuka perilaku komponen;

b. Reusability, yaitu merancang dan merakit komponen yang sudah

ada (di dalam atau di seluruh domain) dalam mengembangkan

komponen baru;

c. Software Quality, yaitu penjaminan kualitas perangkat lunak

yang terukur; dan

d. Maintainability, yaitu pengembangan yang mudah atas sebuah

sistem.