perancangan dengan pemakaian ulang · pdf filememahami pengertian kerabat aplikasi dan...
TRANSCRIPT
PERANCANGAN DENGAN
PEMAKAIAN ULANG
REKAYASA PERANGKAT LUNAK
(SOFTWARE ENGINEERING)
P
T
I
K
Tujuan Memahami keuntungan pemakaian ulang komponen-
komponen perangkat lunak dan beberapa masalah pemakaian ulang dapat muncul
Memahami berbagai tipe komponen yang dapat dipakai ulang dan proses-proses perancangan komponen-komponen untuk pemakaian ulang tersebut
Memahami pengertian kerabat aplikasi dan memahami bagaimana kerabat aplikasi merupakan cara yang efektif dalam pemakaian ulang perangkat lunak
Memahami bagaimana pola merupakan abstraksi tingkat tinggi yang mempromosikan perancangan dengan pemakaian ulang pada pengembangan berorientasi objek
Materi
Pengembangan Berbasis Komponen
Kerabat Aplikasi
Pola Perancangan
Literatur
Sommerville, Ian; Software Engineering, 6th
Addison Wesley Publishing Company, 2001
Pendahuluan • Proses perancangan pada sebagian besar disiplin ilmu didasarkan
pada pemakaian ulang komponen
• 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
• Pemakaian ulang yang sistematik menuntut proses perancangan
yang mempertimbangkan bagaimana desain yang sudah ada dapat
dipakai ulang dan secara ekplisit membuat desain berdasarkan
komponen perangkat yang sudah ada.
Pendahuluan
• 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, misalnya:
1) Pemakaian Ulang Sistem Aplikasi
2) Pemakaian Ulang Komponen
3) Pemakaian Ulang Fungsi
• Keuntungan yang jelas dari metode ini adalah diperkecilnya biaya
pengembangan secara keseluruhan.
Pendahuluan
Keuntungan pemakaian ulang perangkat lunak
Keuntungan Keterangan
Keandalan bertambah Komponen yang dipakai ulang, yang telah
digunakan pada system yang berjalan, seharusnya
lebih dapat diandalkan daripada komponen baru.
Komponen ini telah digunakan dan diuji pada
berbagi lingkungan. Kesalahan perancangan dan
implementasi ditemukan dan dihilangkan pada
pemakaia 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.
Pendahuluan
Keuntungan Keterangan
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 mengenkapsulasi pengetahuan
mereka
Pemenuhan standar Beberapa standar, seperti standar interface,
dapat diimplementasikan sebagai satu set
komponen standar.
Pengembangan yang dipercepat Membawa suatu system ke pasar secepat
mungkin, seringkali lebih penting dari biaya
pengembangan keseluruhan. Pemakaian
ulang komponen mempercepat produksi
karena waktu pengembangan dan waktu
validasi dan dipersingkat
Pendahulan
• Ada tiga persyaratan kritis perancangan dan
pengembangan perangkat lunak dengan pemakaian
ulang sebagai berikut :
1. Komponen yang dapat dipaki ulang dan sesuai, harus
mungkin ditemukan.
2. Pemakaian ulang komponen harus pasti bahwa
komponen-komponen tersebut akan bekerja.
3. Komponen tersebut harus memiliki dokumentasi yang
berhubungan untuk pemakai ulang memahaminya dan
mengadaptasinya ke aplikasi yang baru.
Pendahuluan
• Pemakaian ulang berbasis generator
Pendahuluan
• Keterangan Pemakaian ulang berbasis generator
Alternatif bagi pandangan berorientasi komponen pemakaian ulang
adalah pandangan generator.
. Pada pendekatan terhadap pemakaian ulang ini, pengetahuan
yang dapat dipakai ulang di tangkap pada system generator
program yang dapat deprogram dalam bahasa berorientasi domain.
. Dengan menggunakan informasi ini, suatu system perangkat lunak
operasional dapat dibangkitkan. Pemakaian ulang berbasis
generator hanya mungkin jika abstraksi domain dan pemetaannya
pada kode eksekusi dapat diidentifikasi.
Pengembangan Berbasis
Komponen • Pendekatan berbasis pemakaian ulang terhadap
pengembangan sistem perangkat lunak.
• Komponen lebih abstrak dari kelas objek dan dianggap
sebagai penyedia layanan yang berdiri sendiri.
• Ketika sistem membutuhkan layanan, sistem memanggil
komponen untuk menyediakan layanan tersebut tanpa
peduli dimana komponen tersebut berjalan atau bahasa
pemrograman yang dipakai untuk mengembangkannya.
Pengembangan Berbasis
Komponen • 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.
2. Komponen mengeluarkan interface mereka dan semua
interaksi melalui interface tersebut. Interface komponen
dinyatakan dalam operasi yang diparameterisasi dan
status internalnya tidak akan diperlihatkan
Pengembangan Berbasis
Komponen • Komponen didefinisikan oleh interfacenya dan, dalam kasus yang
paling umum dianggap memiliki dua interface yang berhubungan.
Biar lebih jelas dibawah ini merupakan interface komponen
Pengembangan Berbasis
Komponen • Interface komponen ada dua :
Interface provides, interface yang mendefinisikan
layanan uang disediakan oleh komponen tersebut.
Interface requires inteface yang menspesifikasikan
layanan apa yang harus tersedia dari sistem yang
memakai komponen itu. Jika tidak disediakan maka
komponen tidak akan bekerja
Pengembangan Berbasis
Komponen • Pengembangan Layanan Percetakan
Pengembangan Berbasis
Komponen • Keterangan gambar pengembangan layanan percetakan
Dalam hal ini, layanan yang disediakan adalah layanan untuk
mencetak sebuah dokumen, untuk menemukan status antrian yang
berhubungan dengan suatu printer tertentu, untuk mencatat dan
menghapus sebuah printer dengan komponen layanan pencetakan,
untuk memindahkan tugas pencetakan .
Persyaratan untuk komponen ini adalah bahwa platform yang
mendasarinya harus menyediakan layanan yan dinamakan
GetPDFile untuk mengambil file deskripsi printer untuk suatu tipe
printer dan layanan yang bernama PrintInt yang mentransfer
command ke printer yang spesifikasi
Pengembangan Berbasis
Komponen • Komponen-komponen bisa eksis pada tingkat abstraksi
yang berbeda –beda, dari subrutin library yang
sederhana sampai seluruh aplikasi.
• Mayer (1999) mengidentifikasi lima tingkat abstraksi:
1. Abstaksi data, komponen mengimplementasi satu
fungsi, mis fungsi matematika.
2. Pengelompokkan Kasual, komponen sekumpulan
entitas yang berhubungan longgar yang mungkin
berupa deklarasi data, fungsi dsb
Pengembangan Berbasis
Komponen • Lanjutan…
3. Abstraksi Data, komponen mempresentasikan
abstraksi data atau kelas perangkat lunak bahasa
berorientasi objek.
4. Abstraksi Cluster, komponen merupakan sekumpulan
kelas yang berhubungan yang bekerja sama kadang
dinamakan kerangka kerja.
5. Abstraksi Sistem komponen merupakan sistem yang
sepenuhnya berdiri sendiri.
Pengembangan Berbasis
Komponen • Pengembangan berorientasi komponen dapat diintegrasikan ke
dalam proses pengembangan sistem dengan menggunakan
kegiatan pemakaian ulang yang spesifik sebagaimana gambar
dibawah ini.
Pengembangan Berbasis
Komponen • Keterangan proses pemakaian ulang oportunistik
Perancang system menyelesaikan perancangan tingkat tinggi dan
spesifikasi kompomen desain tersebut. Spesifikasi ini digunakan
untuk menemukan komponen yang akan dipakai ulang. Spesifikasi
ini mungkin dimasukkan pada tingkat arsitektural atau pada
perancangan yang lebih rinci.
Pengembangan Berbasis
Komponen • Mungkin kesulitan utama dalam pengembangan berbasis komponen
adalah masalah pemeliharan dan evolusinya.
• Biasanya source code komponen tidak tersedia dan berubahnya
persyaratan aplikasi, tidak mungkin bagi kita untuk mengubah
komponen demi merefleksikan persyaratan-persyaratan ini.
• Pilihan untuk mengubah persyarata pada tahap ini, untuk
menyesuaikan dengan komponen yang tersedia, biasanya tidak
mungkin karena aplikasi sudah dipakai.
• Diperlukan pekerjaan tambahan untuk memakai ulang komponen
dan, dengan berlalunya waktu, hal ini mengakibatkan biaya
pemeliharaan bertambah.
Pengembangan Berbasis
Komponen • Pengembangan dengan pemakaian ulang
Pengembangan Berbasis
Komponen • Pengembangan dengan pemakaian ulang
• Pada pengembangan yang didorong oleh pemakaian ulang,
persyratan system dimodifikasi menurut komponen pemakaian
ulang (reusable) yang tersedia.
• Desain juga di dasarkan atas komponen-komponen yang tersedia
itu. Ini berarti bahwa mungkin saja harus terjadi kompromi
persyaratan.
• Desain mungkin kurang efisien dari desain khusus. Namun biaya
pengembangan yang lebih kecil, pengiriman system yang lebih
cepat, dan keandalan system yang bertambah seharusnya dapat
mengkompensasi hal ini.
Kerangka Kerja Aplikasi
• Kerangka kerja (atau kerangka kerja aplikasi) merupakan desain
subsistem yang terdiri dari sekumpulan yang abstrak dan konkret,
dan berbagai interface diantara mereka (Wirfs-Brock dan Johnson,
1990).
• Rincian khusus mengenai subsistem aplikasi sistem
diimplementasikan dengan menambahkan komponen dan
menyediakan implementasi yang konkret dari kelas abstrak pada
kerangka kerja.
• Kerangka kerja jarang merupakan aplikasi sendiri. Aplikasi
biiasanya dibangun dengan mengintegrasikan sejumlah kerangka
kerja.
Kerangka Kerja Aplikasi
• Fayad dan Schmidt (1997) menfidentifikasikan tiga kelas
kerangka kerja:
1. Kerangka kerja infrastruktur sistem. Kerangka kerja ini
mendukung pengembangan infrastruktur sistem seperti
komunikasi, interface user dan compiler. (Schmidt,
1997).
2. Kerangka kerja integrasi middleware ( perangkat
menengah ). Kerangka kerja ini terdiri dari satu set
standar dan kelas objek yang berhubungan yang
mendukung komunikasi dan pertukaran informasi
komponen.
Kerangka Kerja Aplikasi
• Lanjutan…
3. Kerangka kerja aplikasi perusahaan ini berhubungan
dengan domain aplikasi yang spesifik seperti sistem
telekomunikasi atau finansial(Baumer et al., 1997).
Kerangka kerja ini memiliki pengetahuan domain
aplikasi dan mendukung pengembangan aplikasi end-
user. Kerangka ini berhubungan dengan kerabat
aplikasinya.
Kerangka Kerja Aplikasi
• Kerangka kerja Model View-Controller
Kerangka Kerja Aplikasi
• Keterangan Kerangka kerja Model View-Controller
• Salah satu kerangka kerja yang paling dikenal dan banyak
digunakan untuk perancangan GUI adalah kerangka kerja MVC.
• kerangka kerja ini pada awalnya diusulkan sebagai pendekatan
terhadap perancangan GUI yang memungkinkan presentasi multipel
dari sebuah objek dan gaya interaksi yang berbeda dengan setiap
presentasi ini
• Kerangka kerja MVC mendukung presentasi data dengan cara-cara
yang berbeda dan interaksi yang terpisah dengan setiap presentasi
ini.
• Ketika data dimodifikasi melalui salah satu dari presentasi tersebut,
semua presentasi lain diupdate.
Kerangka Kerja Aplikasi • Aplikasi yang dibangun dengan menggunakan kerja bisa menjadi
dasar untuk pemakaian ulang lebih jauh melalui konsep kerabat
aplikasi.
• Masalah yang mendasar dengan kerangka kerja adalah
kompleksitas bawaannya dan waktu yang diperlukan untuk belajar
menggunakannya.
• Mungkin dibutuhkan beberapa bulan untuk memahami kerangka
kerja sepenuhnya.
• Pada organisasi besar, beberapa perekayasa perangkat lunak
menjadi spesialis kerangka kerja.
• Tidak ada keraguan bahwa pendekatan ini merupakan pendekatan
yang efektif terhadap pemakaian ulang tetapi biaya pengenalan
yang tinggi membatasi pemakaian secara luas
Pemakaian Ulang Produk
COTS • Istilah produk COTS (Commersial Off The Self/Komersil
dan Siap Beli) dapat, pada prinsipnya, berlaku bagi
komponen manapun yang ditawarkan oleh vendor pihak
ketiga.
• Istilah COTS digunakan untuk mengacu produk perangkat
lunak sistem.
• Fungsionalitas dari COTS ialah sistem ini lebih luas dari
komponen khusus, keuntungan yang potensial melalui
pemakaian ulang akan bertambah.
• Sistem database mungkin merupakan contoh yang paling
baik dari COTS
Pemakaian Ulang Produk
COTS • Pada prinsipnya, penggunaan sistem COTS
berskala besar sama dengan penggunaan
komponen yang lebih khusus lainnya.
• Namun demikian, kenyataan bahwa produk-
produk ini biasanya merupakan sistem besar
dan seringkali dijual sebagai sistem yang
terpisah dan berdiri sendiri membawa masalah
tambahan.
Pemakaian Ulang Produk
COTS • Boehm (1999) membahas empat masalah dengan
integrasi sistem COTS :
Tidak adanya kontrol terhadap fungsionalitas dan
kinerja.
Masalah dengan kemampuan antar operasi sistem
COTS
Tidak ada kontrol terhadap evolusi sistem
Dukungan dari vendor COTS
Pemakaian Ulang Produk
COTS • Keuntungan pemakaian ulang produk COTS sangat
signifikan karena sistem-sistem ini memberikan begitu
banyak fungsionalitas bagi pemakai ulang.
• Usaha implementasi yang berbulan-bulan atau bahkan
bertahun-tahun dapat dipersingkat jika sistem yang ada
dipakai ulang dan waktu pengembangan sistem pun
diperkecil secara drastis.
• Dengan kenyataan bahwa penyerahan sistem yang
cepat merupakan persyaratan utama untuk banyak
sistem.
Pengembangan Komponen
Untuk Pemakaian Ulang • Proses pengembangan komponen yang ideal harus
merupakan proses berbasis pengalaman, dimana
komponen pemakaian ulang khusus dibuat dari
komponen yang ada yang telah dipakai ulang dengan
cara yang oportunis.
• Dengan menggunakan pengetahuan mengenai masalah
pemakaian ulang dan diadaptasi komponen yang
dibutuhkan untuk mendukung pemakaian ulang, versi
komponen yang lebih dapat dipakai ualng dan dibuat
Pengembangan Komponen
Untuk Pemakaian Ulang • Ada berbagai karakteristik komponen yang
menghasilkan kemampuan untuk dipakai ulang:
1. Komponen harus merefleksikan abstraksi domain yang
stabil. Abstraksi domain yang stabil merupakan konsep
mendasar pada domain aplikasi yang berubah
perlahan.
2. Komponen harus menyembunyikan cara statusnya
direprensentasikan dan harus menyediakan operasi
yang memungkinkan status tersebut diakses dan dial-
up date
Pengembangan Komponen
Untuk Pemakaian Ulang • Lanjutan…
• Komponen harus seindependen mungkin. Idealnya, sebuah
komponen harus berdiri sendiri sehingga komponen tidak
memerlukan komponen harus berdiri sendiri sehingga komponen
tidak memerlukan komponen lain untuk beroperasi. Yang paling
baik dilakukan adalah meminimasi ketergantungan ini, terutama jika
ada ketergantungan pada komponen-komponen yang dapat
berubah seperti fungsi sistem operasi.
• Semua eksepsi harus merupakan bagian dari interface komponen.
Komponen tidak boleh menangani eksepsi sendiri karena aplikasi
yang berbeda akan memiliki persyaratan yang berbeda untuk
penanganan eksepsi.
Pengembangan Komponen
Untuk Pemakaian Ulang • Untuk membuat komponen-komponen ini dapat dipakai
ulang, biasanya perlu dibuat sebuah wrapper(pembungkus).
• Wrapper menyembunyikan kompleksitas kode yang
mendasarinya dan menyediakan interface untuk komponen
eksternal untuk mengakses layanan yang diberikan.
• Membuat komponen yang dapat dipakai ulang menuntut
adanya interface yang sederhana dan minimal yang mudah
dimengerti.
• Kemampuan pemakaian ulang menambah kompleksitas
dan dengan demikian mengurangi pemahaman komponen.
Kerabat Aplikasi
• Sebuah kerabat aplikasi atau kalur produk
merupakansatu set aplikasi yang memiliki arsitektur
spesifik domain.
• Inti umum dari kerabat aplikasi dipakai ulang setiap kali
dibutuhkan aplikasi baru.
• Pengembangan baru bisa melibatkan penulisan
beberapa komponen tambahan dan adaptasi beberapa
komponen pada aplikasi untuk memenuhi permintaan
baru.
Kerabat Aplikasi
• Ada berbagai jenis spesialisasi kerabat aplikasi yang
dapat dikembangkan.
Spesialisasi Platform, dimana berbagai versi aplikasi
dikembangkan untuk berbagai platform.
Spesialisasi Konfigurasi, dimana berbagai versi aplikasi
dibuat untuk menangani berbagai piranti periferal.
Spesialisasi Fungsional, dimana berbagai versi aplikasi
dibuat untuk pelanggan dengan persyaratan yang
berbeda.
Kerabat Aplikasi
• Untuk mengilustrasikan pendekatan terhadap pemakaian ulang ini
dapat dilihat gambar arsitektur sistem manajemen inventaris.
Kerabat Aplikasi
• Keterangan gambar sistem manajemen sumber daya generik
Mengilustrasikan arsitektur system untuk manajemen
inventaris. System manajemen inventarisdigunakan oleh
organisasi untuk dapat mengetahui asset mereka setiap
saat.
System ini harus menyediakan fasilitas seperti (add)
kemampuan untuk menambkan sumberdaya ke inventaris,
(remove) kemampuan untuk mengambil sumberdaya dari
inventaris, (query) kemmampuan unntuk mencari dan
(browse) menelusuri inventaris, dan (create report)
kemampuan untuk membuat laporan.
Kerabat Aplikasi
• Dalam implmentasi dari manajemen sumber daya ada
pada gambar dibawah ini yaitu sistem perpustakaan
Kerabat Aplikasi
• Keterangan gambar sitem perpustakaan
Pembuatan sistem ini melibatkan penambahan fasilitas
baru untuk mengeluarkan dan mengembalikan sumber
daya dan memungkinkan user pada sistem, fasilitas ini
ditunjukkan disebelah kanan pada gambar.
Pada umumnya, pengembangan aplikasi dengan
mengadaptasi versi generik dari aplikasi tersebut
memiliki arti bahwa sebagian besar kode aplikasi dipakai
ulang.
Kerabat Aplikasi
• Gambar dibawah ini menunjukkan langkah-langkah yang terdapat
dalam adaptasi kerabat aplikasi untuk membuat aplikasi baru.
• Detil proses ini mungkin berbeda secara radikal, tergantung pada
domain aplikasi dan lingkungan organisasi sistem.
Kerabat Aplikasi
• Keterangan gambar pengembangan anggota kerabat
Elisitasi persyaratan stakeholder, biasanya langkah ini
melibatkan demonstrasi dan eksperimen dengan system
tersebut dan menyatakan persyaratan sebagai
modifikasi yang diperlukan
Pilih anggota kerabat yang paling sesuai, persyaratan
dianalisis dan anggota kerabat yang paling sesuai untuk
persyaratan-persyaratan ini dipilih untuk dimodifikasi.
Negosiasi ulang persyaratan, ada negosiasi ulang
persyaratan untuk meminimmasi perubahan yang
diperlukan.
Kerabat Aplikasi
• Lanjutan…
Adaptasi system yang sudah ada, modul-modul baru
dikembangkan untuk system yang sudah ada dan
modul-modul system yang telah ada diadaptasibuntuk
memenuhi persyratan-persyaratan baru.
Serahkan anggota kerabat yang baru. anggota kerabat
aplikasi yang baru diserahkan kepada pelanggan. Pada
tahap ini anda harus mendokumentasikan fitur-fitur
kuncinya sehingga dapat dipakai ulang sebagai dasar
untuk pengenmbangan system lainnya di masa datang
Kerabat Aplikasi
• Dengan beberapa pengecualian kerabat aplikasi
biasanya muncul dari aplikasi yang sudah ada. Yaitu
organisasi mengembangkan aplikasi dan kemudian
ketika dibutuhkan sebuah aplikasi baru menggunakan
aplikasi baru menyebabkan proses ini berkelanjutan.
• Namun demikian karena perubahan cenderung merusak
struktur aplikasi pada suatu tahap diambil keputusan
khusus untuk merancang kerabat aplikasi yang generik.
Pola Rancangan
• Satu cara untuk mengatasi masalah ini adalah
memakai ulang rancangan yang lebih abstrak
yang tidak mencakup rincian implmentasi.
• Rancangan ini kemudian diimplementasi khusus
untuk menyesuaikan dengan persyaratan
aplikasi.
Pola Rancangan
• Pola rancangan (Gamma et al…1995) diturunkan dari ide
dikemukakan oleh Christopus Alexander(Alexander et al,.1977)
yang mengusulkan bahwa ada pola tertentu pada rancangan
pembangunan yang umum dan sekaligus memuaskan dan efektif.
• Pola merupakan deskripsi masalah dan inti solusinya sehingga
solusi tersebut dapat dipakai ulang pada setting yang berbeda.
• Pada perancangan perangkat lunak, pola rancangan telah
dihubungkan dengan desain berorientasi objek.
• Pola ini seringkali bergantung pada karakteristik objek inheritansi
dan polimorfisme untuk memberikan generalitas.
Pola Rancangan
• Gamma et el., (1995) mendefinisikan empat elemen yang penting
pada pola rancangan:
1. Nama yang merupakan referensi yang bermakna terhadap pola
2. Deskripisi area masalah yang menjelaskan kapan pola tersebut
dapat diterapkan.
3. Deskripsi solusi yang mendeskripisikan bagian-bagian solusi
perancangan, hubungannya dan tanggung jawabnya.
4. Pernyataan konsekuensi hasil dan pengukuran perapan pola
tersebut.
Pola Rancangan
• Penggunaan pola hanya merupak bentuk yang sangat
efektif dari pemakaian ulang, tetapi cara ini memiliki
biaya pengenalan yang tinggi untuk proses
perancangannya dan hanya dapat dipakai oleh
programmer yang berpengalaman.
• Pola hanya sesuai dengan programmer yang
berpengalaman karena mereka mengenali situasi
generik di mana suatu pola dapat diterapkan.
Hal-Hal Penting • Perancangan dengan pemakaian ulang melibatkan perancangan
perangkat lunak disekitar contoh perancangan bagus yang tersedia
dan melibatkan juga pemakaian komponen komponen perangkat
lunak jika ada.
• Keuntungan pemakaian ulang perangkat lunak adalah biaya yang
lebih rendah, pengembangan perangkat lunak yang lebih cepat dan
resiko yang lebih kecil. Keandalan sistem bertambah dan spesialis
dapat bekerja lebih efektif dengan berkonsentrasi pada kepakaran
mereka pada perancangan komponen yang dapat dipakai ulang.
• Pemakai ulang produk COTS berkenaan dengan pemakaian ulang
sistem berskala besar dan siap dibeli. Produk-produk ini
memberikan banyak fungsionalitas dan pemakaian ulangnya dapat
secara radikal memperkecil biaya waktu dan pengembangan.
Hal-Hal Penting
• Komponen-komponen perangkat lunak yang telah
dirancang untuk dipakai ulang harus independen, harus
merefleksikan abstraksi domain yang stabil, harus
menyediakan akses ke status melalui operasi interface
dan tidak boleh menangani eksepensi sendiri.
• Kerabat aplikasi adalah aplikasi yang berhubungan
yang dikembangkan dari satu atau lebih aplikasi dasar
• Pola desain adalah abstraksi tingkat tinggi yang
mendokumentasikan solusi desain yang berhasil.
Terima Kasih