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
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 generatorPendahuluan
• 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 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
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 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
Kerangka Kerja Aplikasi
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
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 produkmerupakansatu 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
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)
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
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.