tujuan

Tujuan dari bab ini adalah untuk memperkenalkan penggunaan kembali perangkat lunak dan
menggambarkan pendekatan untuk pengembangan sistem berdasarkan sistem skala besar
menggunakan kembali. Bila Anda telah membaca bab ini, Anda akan:

memahami manfaat dan masalah menggunakan kembali perangkat lunak saat
mengembangkan sistem baru;

memahami konsep kerangka aplikasi sebagai seperangkat
benda dapat digunakan kembali dan bagaimana kerangka kerja dapat digunakan dalam aplikasi
pembangunan;

telah diperkenalkan ke lini produk perangkat lunak, yang terdiri dari
arsitektur inti umum dan dikonfigurasi, komponen dapat digunakan kembali;

telah belajar bagaimana sistem dapat dikembangkan dengan mengkonfigurasi dan
menyusun sistem off-the-shelf software aplikasi.
isi
1
6.1
Penggunaan kembali lanskap
1
6.2
kerangka aplikasi
1
6.3
Lini produk Software
1
6.4
Reuse produk COTS

Rekayasa perangkat lunak berbasis Reuse adalah strategi rekayasa perangkat lunak di mana bangan
yang
Proses ngunan ditujukan untuk menggunakan kembali perangkat lunak yang ada. Meskipun penggunaan
kembali diusulkan
sebagai strategi pembangunan lebih dari 40 tahun yang lalu (McIlroy, 1968), hanya karena
2
0
0
0
bahwa 'pembangunan dengan reuse' telah menjadi norma bagi sistem bisnis baru.
Pindah ke pembangunan berbasis reuse telah menanggapi tuntutan yang lebih rendah
produksi perangkat lunak dan biaya pemeliharaan, pengiriman lebih cepat dari sistem, dan peningkatan
kualitas perangkat lunak. Semakin banyak perusahaan melihat software mereka sebagai aset berharga.
Mereka mempromosikan penggunaan kembali untuk meningkatkan laba atas investasi perangkat lunak.
Ketersediaan perangkat lunak dapat digunakan kembali telah meningkat secara dramatis. The open
source
Gerakan berarti bahwa ada besar dapat digunakan kembali kode dasar tersedia dengan biaya rendah.
Hal ini mungkin dalam bentuk perpustakaan program atau seluruh aplikasi. Ada banyak
domain-spesifik sistem aplikasi yang tersedia yang dapat disesuaikan dan disesuaikan dengan
kebutuhan perusahaan tertentu. Beberapa perusahaan besar menyediakan berbagai com dapat
digunakan kembali
ponents bagi para pelanggan mereka. Standar, seperti standar layanan web, telah membuat
lebih mudah untuk mengembangkan layanan umum dan menggunakan kembali mereka di berbagai
aplikasi.
Rekayasa perangkat lunak berbasis Reuse adalah sebuah pendekatan untuk pembangunan yang
mencoba untuk
memaksimalkan penggunaan kembali perangkat lunak yang ada. Unit perangkat lunak yang digunakan
kembali mungkin
ukuran yang berbeda secara radikal. Sebagai contoh:
1.
Sistem aplikasi menggunakan kembali Seluruh sistem aplikasi dapat digunakan kembali oleh
menggabungkan tanpa berubah menjadi sistem lain atau dengan mengkonfigurasi
aplikasi untuk pelanggan yang berbeda. Atau, keluarga aplikasi yang memiliki
arsitektur yang umum, tetapi yang disesuaikan untuk pelanggan tertentu, mungkin
dikembangkan. Aku menutup aplikasi reuse sistem kemudian dalam bab ini.
2.
Komponen reuse Komponen aplikasi, mulai dari ukuran subsys-
tems ke objek tunggal, dapat digunakan kembali. Sebagai contoh, sistem pencocokan pola
dikembangkan sebagai bagian dari sistem pengolahan teks dapat digunakan kembali dalam database
mandat
sistem pengelolaan. Aku menutupi penggunaan kembali komponen dalam Bab 17 dan 19.
3.
Komponen objek dan fungsi Software reuse yang menerapkan fungsi tunggal,
seperti fungsi matematika, atau kelas objek dapat digunakan kembali. Bentuk
reuse, berbasis di sekitar perpustakaan standar, telah umum selama 40 tahun terakhir.
Banyak perpustakaan fungsi dan kelas yang tersedia secara bebas. Anda menggunakan kembali kelas
dan fungsi dalam perpustakaan ini dengan menghubungkan mereka dengan aplikasi baru dikembangkan
kode. Di daerah seperti algoritma matematika dan grafis, di mana khusus
keahlian yang dibutuhkan untuk mengembangkan objek efisien dan fungsi, ini adalah terutama
pendekatan yang efektif.
Sistem perangkat lunak dan komponen entitas berpotensi dapat digunakan kembali, tetapi mereka
sifat khusus kadang-kadang berarti bahwa itu adalah mahal untuk memodifikasi mereka untuk baru
situasi. Bentuk komplementer reuse adalah 'konsep reuse' di mana, daripada menggunakan kembali
komponen perangkat lunak, Anda menggunakan kembali ide, cara, atau kerja atau algoritma. con di
kecuali bahwa Anda menggunakan kembali diwakili dalam notasi abstrak (misalnya, model sistem), yang
tidak termasuk detail implementasi. Hal ini dapat, oleh karena itu, dikonfigurasi dan disesuaikan
untuk berbagai situasi. Reuse konsep dapat diwujudkan dalam pendekatan seperti desain
manfaat Penjelasan
Peningkatan ketergantungan digunakan kembali perangkat lunak, yang telah dicoba dan diuji dalam
sistem kerja, harus
lebih diandalkan daripada perangkat lunak baru. Its desain dan implementasi kesalahan
seharusnya telah ditemukan dan diperbaiki.
Risiko Proses Mengurangi Biaya perangkat lunak yang ada sudah diketahui, sedangkan biaya
pembangunan
selalu soal penghakiman. Ini merupakan faktor penting untuk proyek
manajemen karena mengurangi margin of error dalam estimasi biaya proyek.
Hal ini terutama berlaku ketika komponen perangkat lunak yang relatif besar seperti
subsistem digunakan kembali.
Efektif menggunakan spesialis Alih-alih melakukan pekerjaan yang sama berulang-ulang, spesialis
aplikasi dapat
mengembangkan perangkat lunak yang dapat digunakan kembali yang merangkum pengetahuan
mereka.
Standar kepatuhan Beberapa standar, seperti standar antarmuka pengguna, dapat diimplementasikan
sebagai satu set
komponen reusable. Misalnya, jika menu dalam antarmuka pengguna diimplementasikan
menggunakan komponen reusable, semua aplikasi menyajikan format menu yang sama untuk
pengguna. Penggunaan antarmuka pengguna standar meningkatkan ketergantungan karena pengguna
membuat kesalahan lebih sedikit ketika disajikan dengan antarmuka akrab.
Percepatan pembangunan Membawa sistem untuk pasar sedini mungkin sering kali lebih penting
daripada
biaya pembangunan secara keseluruhan. Menggunakan kembali perangkat lunak dapat mempercepat
produksi sistem
karena kedua pengembangan dan waktu validasi dapat dikurangi.
pola (dibahas dalam Bab 7), produk sistem dikonfigurasi, dan Program genera-
tor. Ketika konsep digunakan kembali, proses reuse mencakup kegiatan mana
konsep-konsep abstrak yang dipakai untuk membuat komponen reusable dieksekusi.
Keuntungan yang jelas dari penggunaan kembali perangkat lunak adalah bahwa biaya pembangunan
secara keseluruhan harus
dikurangi. Sedikit komponen perangkat lunak harus ditentukan, dirancang, dilaksanakan,
dan divalidasi. Namun, pengurangan biaya adalah hanya salah satu keuntungan dari penggunaan
kembali. Pada Gambar 16.1,
Saya telah terdaftar keuntungan lain dari menggunakan kembali aset perangkat lunak.
Namun, ada biaya dan masalah yang terkait dengan penggunaan kembali (Gambar 16.2). ada
adalah biaya yang signifikan terkait dengan pemahaman apakah komponen adalah
cocok untuk digunakan kembali dalam situasi tertentu, dan dalam pengujian komponen yang untuk
memastikan nya
ketergantungan. Biaya-biaya tambahan berarti bahwa penurunan pengembangan keseluruhan
ment biaya melalui penggunaan kembali mungkin kurang daripada yang diantisipasi.
Seperti yang saya bahas dalam Bab 2, proses pengembangan perangkat lunak harus disesuaikan
untuk digunakan kembali ke rekening. Secara khusus, harus ada penyempurnaan persyaratan
tahap di mana persyaratan untuk sistem dimodifikasi untuk mencerminkan lunak dapat digunakan
kembali
ware yang tersedia. Desain dan implementasi tahap sistem juga dapat
meliputi kegiatan eksplisit untuk mencari dan mengevaluasi komponen kandidat untuk digunakan
kembali.
Penggunaan kembali perangkat lunak yang paling efektif bila direncanakan sebagai bagian dari
organisasi-lebar
menggunakan kembali program tersebut. Sebuah program reuse melibatkan penciptaan aset dapat
digunakan kembali dan
adaptasi proses pembangunan untuk memasukkan aset tersebut dalam perangkat lunak baru.
Pentingnya perencanaan reuse telah diakui selama bertahun-tahun di Jepang
(Matsumoto, 1984), di mana reuse merupakan bagian integral dari 'pabrik' pendekatan Jepang
masalah Penjelasan
Peningkatan biaya pemeliharaan Jika kode sumber dari perangkat lunak sistem digunakan
kembali atau komponen tidak tersedia,
maka biaya pemeliharaan mungkin lebih tinggi karena unsur-unsur digunakan kembali dari
sistem dapat menjadi semakin tidak sesuai dengan perubahan sistem.
Kurangnya alat mendukung Beberapa perangkat lunak tidak mendukung pengembangan dengan
reuse. Mungkin
sulit atau tidak mungkin untuk mengintegrasikan alat-alat ini dengan perpustakaan komponen
sistem. Proses perangkat lunak diasumsikan oleh alat-alat ini mungkin tidak mengambil reuse
ke rekening. Hal ini terutama berlaku untuk alat-alat yang mendukung tertanam
rekayasa sistem, kurang begitu untuk alat pengembangan berorientasi objek.
Tidak ditemukan-di sini sindrom Beberapa insinyur perangkat lunak memilih untuk menulis
ulang komponen karena mereka
percaya bahwa mereka dapat memperbaiki mereka. Hal ini sebagian untuk melakukan dengan
kepercayaan dan sebagian
hubungannya dengan fakta bahwa menulis perangkat lunak asli dipandang lebih
menantang daripada menggunakan kembali software orang lain.
Menciptakan, memelihara, dan
menggunakan perpustakaan komponen
Mengisi perpustakaan komponen dapat digunakan kembali dan menjamin bahwa perangkat
lunak
pengembang dapat menggunakan library ini bisa mahal. proses pembangunan
harus disesuaikan untuk memastikan bahwa perpustakaan digunakan.
Finding, pemahaman, dan
mengadaptasi dapat digunakan kembali
komponen
Komponen perangkat lunak harus ditemukan di perpustakaan, dipahami dan,
kadang-kadang, diadaptasi untuk bekerja di lingkungan yang baru. Insinyur harus
cukup yakin untuk menemukan komponen di perpustakaan sebelum mereka
termasuk pencarian komponen sebagai bagian dari proses perkembangan normal mereka.

untuk pengembangan perangkat lunak (Cusamano, 1989). Perusahaan seperti Hewlett-Packard
juga telah sangat berhasil dalam program reuse mereka (Griss dan Wosser, 1995), dan
pengalaman mereka telah didokumentasikan dalam sebuah buku oleh Jacobson et al. (1997).
Penggunaan kembali lanskap
Selama 20 tahun terakhir, banyak teknik telah dikembangkan untuk mendukung perangkat lunak
menggunakan kembali. Teknik ini memanfaatkan fakta bahwa sistem dalam domain aplikasi yang sama
mirip dan memiliki potensi untuk digunakan kembali; reuse yang mungkin pada tingkat yang berbeda
dari
fungsi sederhana untuk menyelesaikan aplikasi; dan bahwa standar untuk komponen reusable
memfasilitasi reuse. Gambar 16.3 mengatur tentang sejumlah kemungkinan cara pelaksanaan
penggunaan kembali perangkat lunak, dengan masing-masing dijelaskan secara singkat pada Gambar
16.4.
Mengingat array ini teknik untuk digunakan kembali, pertanyaan kuncinya adalah "yang paling
teknik yang tepat untuk digunakan dalam situasi tertentu? "Jelas, ini tergantung pada
persyaratan untuk sistem yang dikembangkan, aset teknologi dan dapat digunakan kembali
tersedia, dan keahlian dari tim pengembangan. Faktor-faktor utama yang Anda harus
dipertimbangkan ketika merencanakan penggunaan kembali adalah:
1. jadwal pengembangan untuk perangkat lunak Jika perangkat lunak harus dikembangkan
cepat, Anda harus mencoba untuk menggunakan kembali off-the-shelf sistem daripada individual
komponen. Ini adalah besar-grain aset dapat digunakan kembali. Meskipun cocok untuk

persyaratan mungkin tidak sempurna, pendekatan ini meminimalkan jumlah pembangunan
diperlukan.
2 seumur hidup perangkat lunak yang diharapkan Jika Anda sedang mengembangkan sebuah sistem
lama seumur hidup, Anda
harus fokus pada pemeliharaan sistem. Anda seharusnya tidak hanya berpikir
tentang manfaat langsung dari penggunaan kembali tetapi juga implikasi jangka panjang.
Selama masa pakainya, Anda harus menyesuaikan sistem dengan persyaratan baru, yang
akan berarti membuat perubahan pada bagian dari sistem. Jika Anda tidak memiliki akses ke
kode sumber, Anda dapat memilih untuk menghindari off-the-rak komponen dan sistem
dari pemasok eksternal; pemasok mungkin tidak dapat melanjutkan dukungan untuk
kembali perangkat lunak.
3. latar belakang, keahlian, dan pengalaman tim pengembangan teknologi reuse Semua
cukup kompleks dan Anda perlu cukup banyak waktu untuk memahami dan
menggunakannya secara efektif. Oleh karena itu, jika tim pengembangan memiliki keterampilan dalam
tertentu
daerah, ini mungkin di mana Anda harus fokus.
4. kekritisan dari perangkat lunak dan kebutuhan non-fungsional Untuk kritis
sistem yang harus disertifikasi oleh regulator eksternal, Anda mungkin harus membuat
ketergantungan kasus untuk sistem (dibahas dalam Bab 15). Hal ini sulit jika
Anda tidak memiliki akses ke kode sumber dari perangkat lunak. Jika perangkat lunak Anda memiliki
persyaratan kinerja yang ketat, mungkin mustahil untuk menggunakan strategi tersebut
sebagai reuse berbasis-generator, di mana Anda menghasilkan kode dari domainspecific dapat
digunakan kembali
representasi dari suatu sistem. Sistem ini sering menghasilkan relatif
kode tidak efisien.
5. domain aplikasi Dalam beberapa domain aplikasi, seperti manufaktur
dan sistem informasi medis, ada beberapa produk generik yang mungkin
digunakan kembali dengan mengkonfigurasi mereka untuk situasi lokal. Jika Anda bekerja di seperti
domain, Anda harus selalu mempertimbangkan ini sebagai pilihan.
pendekatan Deskripsi
Pola arsitektur arsitektur perangkat lunak standar yang mendukung jenis umum
sistem aplikasi yang digunakan sebagai dasar aplikasi.
Dijelaskan dalam Bab 6, 13, dan Bab 20.
Desain pola abstraksi generik yang terjadi di seluruh aplikasi
direpresentasikan sebagai pola desain menunjukkan abstrak dan konkret
benda dan interaksi. Dijelaskan dalam Bab 7.
Sistem pembangunan berbasis komponen dikembangkan dengan mengintegrasikan komponen (koleksi
benda) yang sesuai dengan standar komponen model. dijelaskan
pada Bab 17.
Kerangka aplikasi Koleksi kelas abstrak dan konkret disesuaikan dan
diperpanjang untuk membuat sistem aplikasi.
Sistem warisan sistem pembungkus Legacy (lihat Bab 9) yang 'dibungkus' dengan mendefinisikan set
interface dan menyediakan akses ke sistem warisan ini
melalui antarmuka ini.
Sistem sistem pelayanan yang berorientasi dikembangkan dengan menghubungkan layanan bersama,
yang mungkin
eksternal yang tersedia. Dijelaskan dalam Bab 19.
Software lini produk Sebuah tipe aplikasi umum di sekitar arsitektur yang umum
sehingga dapat disesuaikan untuk pelanggan yang berbeda.
COTS Sistem reuse produk dikembangkan dengan mengkonfigurasi dan mengintegrasikan ada
sistem aplikasi.
Sistem ERP sistem skala besar yang merangkum bisnis generik
fungsi dan aturan dikonfigurasi untuk sebuah organisasi.
Aplikasi vertikal dikonfigurasi sistem Generik dirancang sehingga mereka dapat dikonfigurasi untuk
kebutuhan pelanggan secara spesifik.
Program perpustakaan Kelas dan fungsi perpustakaan yang mengimplementasikan umum digunakan
abstraksi tersedia untuk digunakan kembali.
Software engineering Model-driven direpresentasikan sebagai model domain dan implementasi
model independen dan kode yang dihasilkan dari model ini.
Dijelaskan dalam Bab 5.
Generator Program Sebuah sistem generator komprehensif pengetahuan tentang jenis aplikasi
dan digunakan untuk menghasilkan sistem dalam domain yang dari usersupplied
model sistem.
Pengembangan perangkat lunak berorientasi aspek komponen bersama yang ditenun menjadi sebuah
aplikasi di berbagai
tempat ketika program dikompilasi. Dijelaskan dalam Bab 21
6 Platform yang digunakan oleh sistem akan berjalan Beberapa model komponen, seperti
NET, khusus untuk platform Microsoft. Demikian pula, sistem aplikasi generik
mungkin platform-spesifik dan Anda mungkin hanya dapat menggunakan kembali ini jika Anda
Sistem ini dirancang untuk platform yang sama.

Berbagai teknik reuse tersedia adalah sedemikian rupa sehingga, dalam banyak situasi, ada
kemungkinan beberapa penggunaan kembali perangkat lunak. Apakah atau tidak menggunakan kembali
dicapai sering
manajerial dan bukan masalah teknis. Manajer mungkin tidak mau berkompromi
persyaratan mereka untuk memungkinkan komponen dapat digunakan kembali untuk digunakan.
Mereka mungkin tidak mengerti
risiko yang terkait dengan penggunaan kembali serta mereka memahami risiko dari aslinya
pembangunan. Meskipun risiko pengembangan perangkat lunak baru mungkin lebih tinggi, beberapa
manajer mungkin lebih suka dikenal risiko yang tidak diketahui.
kerangka aplikasi
Penggemar dini untuk pengembangan berorientasi objek menyarankan bahwa salah satu kunci
manfaat menggunakan pendekatan berorientasi objek adalah bahwa objek dapat digunakan
kembali dalam berbagai
sistem. Namun, pengalaman menunjukkan bahwa benda sering terlalu kecil dan
mengkhususkan diri untuk aplikasi tertentu. Dibutuhkan waktu lebih lama untuk memahami dan
beradaptasi
objek dari reimplement itu. Sekarang telah menjadi jelas bahwa penggunaan kembali berorientasi
objek
paling didukung dalam proses pengembangan berorientasi objek melalui lebih besar-butiran
abstraksi disebut kerangka.
Seperti namanya, kerangka adalah struktur generik yang diperpanjang untuk menciptakan
subsistem atau aplikasi yang lebih spesifik. Schmidt et al. (2004) mendefinisikan kerangka
menjadi:
". . . seperangkat terintegrasi artefak perangkat lunak (seperti kelas, objek dan komponen)
berkolaborasi bahwa untuk menyediakan arsitektur dapat digunakan kembali untuk keluarga
aplikasi yang terkait. "
Kerangka menyediakan dukungan untuk fitur umum yang kemungkinan akan digunakan dalam
semua
aplikasi sejenis. Misalnya, kerangka antarmuka pengguna akan memberikan
dukungan untuk penanganan event antarmuka dan akan mencakup satu set widget yang dapat
digunakan
untuk membangun display. Hal ini kemudian diserahkan kepada pengembang untuk
mengkhususkan ini dengan menambahkan
fungsi spesifik untuk aplikasi tertentu. Misalnya, dalam antarmuka pengguna
kerangka, pengembang mendefinisikan tampilan layout yang sesuai dengan aplikasi
sedang dilaksanakan.
Kerangka mendukung desain ulang dalam bahwa mereka menyediakan arsitektur kerangka untuk
aplikasi serta penggunaan kembali kelas khusus dalam sistem. arsitektur