perancangan dengan pemakaian ulang
DESCRIPTION
TRANSCRIPT
Perancangan dengan Pemakaian Ulang
Arfianti (092904019)
Pendidikan Teknik Informatika dan Komputer Universitas Negeri Makassar
2011
2
Perancangan dengan Pemakaian Ulang
Proses perancangan ulang pada sebagian besar disiplin ilmu ditekankan pada pemakaian ulang komponen.
Perangkat lunak harus dianggap sebagai suatu aset, dan pemakaian ulang aset sangat penting untuk menaikkan pengembangan dari biaya pengembangnya.
Rekayasa perangkat lunak berbasis pemakaian ulang adalah pendekatan terhadap pengembangan yang mencoba memaksimalkan pemakaian perangkat lunak yang ada. Unit perangkat lunak yang dipakai ulang bisa berukuran sangat berbeda.
3
Contoh• Pemakaian ulang sistem aplikasi, yaitu
seluruh sistem aplikasi dapat dipakai ulang dengan menggabungkannya tanpa perubahan dengan sistem lain.
• Pemakaian ulang komponen. Komponen subsistem atau satu objek tunggal aplikasi dapat dipakai ulang.
• Pemakaian ulang fungsi. Komponen perangkat lunak yang menggunakan satu fungsi (contohnya fungsi matematik) dapat dipakai ulang.
4
KeuntunganKeuntungan Keterangan
Keandalan bertambah
Komponen yang dipakai ulang telah diuji pada berbagai lingkungan, sehingga komponen tersebut lebih dapat diandalkan daripada komponen baru.
Resiko proses diperke-cil
Jika komponen telah ada, ketidakpastian biaya pemakaian ulang menjadi lebih kecil daripada biaya pengembangan.
Pemakaian spesialis yang efektif
Spesialis aplikasi tidak melakukan pekerjaan yang sama pada berbagai proyek, tapi mereka dapat mengembangkan komponen-komponen yang dipakai ulang, yang sesuai dengan pengetahuan mereka.
Pemenuhan Standar Pemakaian tampilan antarmuka standar memperbaiki kehandalan, karena pemakai lebih terbiasa menggunakan tampilan antarmuka yang mereka kenal sejak lama.
Pengembangan yang dipercepat
Pemakaian ulang komponen mempercepat proses produksi karena waktu pengembangan dan waktu validasi bisa dipersingkat.
5
Syarat kritis Pengembangan
• Komponen yang dapat dipakai ulang dan sesuai, harus dimiliki dan bisa ditemukan.
• Pemakaian ulang komponen harus memastikan komponen-komponen tersebut bisa bekerja dengan andal dan sebagaimana mestinya.
• Komponen tersebut harus memiliki dokumentasi yang sesuai untuk membantu pemakai ulang memahaminya dan mengadaptasinya ke aplikasi baru.
6
Masalah dan HambatanMasalah Keterangan
Biaya pengembangan perangkat
lunak
Jika source code untuk komponen tidak tersedia, maka biaya pemeliharaan
bertambah besar, karena elemen sistem yang dipakai ulang bisa makin tidak
kompatibel dengan perubahan sistem.
Tidak adanya duku-ngan alat
bantu
Toolset CASE tidak mendukung pengembangan dengan pemakaian ulang.
Integrasi alat bantu ini dengan sistem library sulit bahkan tidak mungkin.
Sindrom tidak dibuat disini. Beberapa perekayasa perangkat lunak kadang-kadang lebih suka menulis kembali
komponen karena mereka yakin dapat membuat kembali suatu komponen yang
dipakai ulang.
Mempertahankan library
komponen
Memenuhi library komponen dan menjamin 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 perangkat lunak belum
matang
Komponen perangkat lunak harus ditemukan pada suatu library, dipahami, dan
diadaptasi untuk bekerja pada lingkungan yang baru.
7
Pandangan Generator
Alternatif untuk pandangan berorientasi komponen pemakaian ulang adalah pandangan generator. Pada pendekatan ini, pengetahuan yang dapat dipakai ulang ditangkap pada sistem generator program yang dapat diprogram dalam bahasa berorientasi domain. Pemakaian berbasis generator hanya mungkin jika abstraksi domain dan pemetaannya pada kode eksekusi dapat diidentifikasi.
8
Pemakaian Ulang Berbasis Generator
Deskripsi Aplikasi
Generator Proses
Program yang dibangkitkan
Pengetahuan Domain Aplikasi
Database
9
• Generator aplikasi untuk pemetaan bisnis. Inputnya berupa 4GL atau interaktif seluruhnya dimana pengguna mendefinisikan tampilan dan aksi pemrosesan. Outputnya berupa program seperti COBOL atau SQL.
• Generator parser untuk pemrosesan bahasa. Inputnya berupa Grammar yang mendeskripsikan bahasa dan Outputnya berupa parser bahasa.
• Generator kode pada CASE tool. Inputnya berupa desain perangkat lunak, dan Outputnya berupa program yang mengimplementasikan sistem yang dirancang.
Pemakaian Berbasis Generator yang Berhasil digunakan
10
Lebih mudah bagi pemakai untuk mengembangkan program dengan menggunakan generator dibandingkan dengan pendekatan berbasis komponen lainnya terhadap pemakaian ulang.
Keuntungan Pandangan Generator
11
Pengembangan berbasis komponen atau rekayasa perangkat lunak berbasis komponen muncul pada akhir tahun 1990-an sebagai pendekatan berbasis pemakaian ulang terhadap pengembangan sistem perangkat lunak. Motivasinya adalah kefrustrasian bahwa pengembangan berorientasi objek tidak berkembang menjadi pemakaian ulang yang ekstensif sebagaimana diperkirakan pada awalnya.
Komponennya lebih abstrak dari kelas objek dan dapat dianggap sebagai penyedia layanan yang berdiri sendiri. Ketika sistem membutuhkan layanan, sistem memanggil komponen untuk menyediakan layanan tersebut tanpa peduli di mana komponen tersebut berjalan atau bahasa pemrograman yang dipakai untuk mengembangkannya.
Pengembangan Berbasis Komponen
12
1. Komponen merupakan entitas yang dapat dieksekusi dan independen. Source code tidak tersedia sehingga komponen tidak dikompilasi dengan komponen sistem lain.
2. Komponen mengeluarkan interface mereka dan semua interaksi melalui inter face tersebut. Interface komponen dinyatakan dalam operasi yang diparamete risasi dan status internalnya tidak pernah diperlihatkan.
Karakteristik Komponen yang dapat dipakai ulang
14
Komponen didefinisikan oleh interfacenya dan, dalam kasus yang paling umum, dapat dianggap memiliki dua interface yang berhubungan
• Interface provides, yaitu interface yang mendefinisikan layanan yang disediakan oleh komponen tersebut
• Interface requires, yaitu interface yang menspesifikasi layanan apa yang harus tersedia dari sistem yang memakai komponen itu. Jika ini tidak disediakan, maka komponen tidak akan bekerja.
15
Contoh : Komponen layanan pencetakan
Print Sevice
GetQueue
Remove
Transfer
GetPDfile
PrinterInt
Interface requires Interface provides
UnRegister
Register
16
Meyer (1999) mengidentifikasi lima tingkat abstraksi:
1. Abstraksi fungsional dimana komponen mengimplementasi satu fungsi, misalnya fungsi matematika.
2. Pengelompokan kasual dimana komponen merupakan sekumpulan entitas yang ber hubungan longgar (loosely related) yang mungkin berupa deklarasi data, fungsi, dsb.
3. Abstraksi data dimana komponen merepresentasikan abstraksi data atau kelas pe rangkat lunak bahasa berorientasi objek.
4. Abstraksi cluster dimana komponen merupakan sekumpulan kelas yang berhubungan yang bekerja sama. Kelas-kelas ini kadang-kadang dinamakan kerangka kerja.
5. Abstraksi sistem dimana komponen merupakan sistem yang sepenuhnya berdiri sendiri.
Tingkat Abstaksi
17
Pengembangan Berorientasi Komponen
Rancangan arsitektur
sistem
Spesifikasi Komponen
Cari komponen yang dapat
dipakai ulang
Pakai komponen yang ditemukan
Pengembangan berorientasi komponen dapat diintegrasikan ke dalam proses pengembangan sistem dengan menggunakan kegiatan pemakaian ulang yang spesifik
Proses pemakaian ulang oportunistik
18
Proses implementasi sistem dengan menggunakan komponen biasanya merupa kan proses pembuatan prototipe atau proses pengembangan inkremental. Bahasa pemrograman standar 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.
19
Pengembangan dengan Pemakaian Ulang
Buat garis besar persyaratan
sistem
Cari komponen yang dapat
dipakai ulang
Modifikasi persyaratan menurut
komponen yang didapat
Perancangan arsitektural
Rancang sistem dengan memakai komponen yang
dapat dipakai ulang
Cari komponen yang dapat
dipakai ulang
20
Pemakaian ulang paling baik didukung pada proses pengembangan berorientasi objek melalui abstraksi yang tidak terlalu detil, yang disebut sebagai kerangka kerja (framework)
Kerangka kerja (atau kerangka kerja aplikasi) merupakan desain subsistem yang terdiri dari sekumpulan kelas yang abstrak dan konkret, dan berbagai interface di antara mereka (Wirfs-Brock dan Johnson, 1990).
Kerangka Kerja Aplikasi
21
Fayad dan Schmidt (1997) mengidentifikasi tiga kelas kerangka kerja:
1. Kerangka kerja infrastruktur sistem yang mendukung pengembangan infrastruktur sistem seperti komunikasi, interface user dan compiler (Schmidt, 1997).
2. Kerangka kerja integrasi middleware (perangkat menengah) yang terdiri dari satu set standar dan kelas objek yang berhubungan yang mendukung komunikasi dan pertukaran informasi komponen.
3. Kerangka kerja aplikasi perusahaan yang berhubungan dengan domain aplikasi yang spesifik seperti sistem telekomunikasi atau finansial (Baumer et al., 1997).
Kerangka-kerangka kerja ini memiliki pengetahuan domain aplikasi dan mendukung pengembangan aplikasi end-user.
Kelas Kerangka Kerja
22
Status view
Metode View
Kerangka Kerja Model-View-Controller
Status kontroler
Metode kontroler
Status model
Metode model
Lihat message modifikasi
Query dan update model
Edit model
Input user
23
Kerangka kerja ini pada awalnya diusulkan pada tahun 1980-an sebagai pendekatan terhadap perancangan GUI yang memungkinkan presen tasi multipel dart 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 part presentasi tersebut, semua presentasi lain di-update.
MVC
24
COST, Commercial Off-The-Shelf Systems merupakan komponen-komponen dari sistem pemakaian ulang yang ditawarkan oleh vendor pihak ketiga.
Pemakaian Ulang Produk COST
25
Boehm (1999) membahas empat masalah dengan integrasi sistem COTS :
1.Tidak adanya kontrol terhadap fungsionalitas dan kinerja.
2.Masalah dengan kemampuan antar operasi sistem COTS.
3.Tidak ada kontrol terhadap evolusi sistem.
4.Dukungan dari vendor COTS.
Masalah Integrasi COST
26
Keuntungan pemakaian ulang produk COTS sangat signifikan karena sistem-sistem ini memberikan begitu banyak fungsio nalitas 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.
Keuntungan COST
27
Proses pengembangan komponen yang ideal harus merupakan proses berbasis pengalaman, di mana komponen pemakaian ulang khusus dibuat dari komponen yang ada yang telah dipakai ulang dengan cara yang oportunis. Dengan meng gunakan pengetahuan mengenai masalah pemakaian ulang dan adaptasi komponen yang dibutuhkan untuk mendukung pemakaian ulang, versi komponen yang lebih generik, yang lebih dapat dipakai ulang, dapat dibuat.
Pengembangan Komponen Untuk Pemakaian Ulang
28
1. Komponen harus merefleksikan abstraksi domain yang stabil. Abstraksi do main yang stabil merupakan konsep mendasar pada domain aplikasi yang berubah perlahan.
2. Komponen harus menyembunyikan cara statusnya direpresentasikan dan harus menyediakan operasi yang memungkinkan status tersebut diakses dan di-up date.
3. Komponen harus seindependen mungkin. Idealnya, sebuah komponen harus berdiri sendiri sehingga komponen tidak memerlukan komponen lain untuk beroperasi.
4. 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.
Karakteristik Komponen yang Dapat Dipakai Ulang
29
Salah satu pendekatan yang paling efektif bagi pemakaian ulang didasarkan sekitar kerabat aplikasi. Sebuah kerabat aplikasi atau jalur produk merupakan satu set aplikasi yang memiliki arsitektur spesifik domain
Namun demikian, setiap aplikasi khusus merupakan spesialisasi dalam satu hal. Inti umum dari kerabat aplikasi dipakai ulang setiap kali dibutuhkan aplikasi bare. Pengembangan barn bisa melibatkan penulisan beberapa komponen tambahan dan adaptasi beberapa komponen pada aplikasi untuk memenuhi permintaan baru.
Kerabat Aplikasi
30
1. Spesialisasi platform, di mana berbagai versi aplikasi dikembangkan untuk ber bagai platform.
2. Spesialisasi konfigurasi, di mana berbagai versi aplikasi dibuat untuk menangani berbagai peranti periferal.
3. Spesialisasi fungsional, di mana berbagai versi aplikasi dibuat untuk pelanggan dengan persyaratan yang berbeda.
Kerabat Aplikasi yang dapat Dikembangkan
31
Library user access
Library Holdings Database
Resource desc. Screen spec. Report spec.
Add Delete Query Browse Admin Report Issue Return Users
Sistem perpustakaan
32
1. Elisitasi persyaratan stakeholder yang didasarkan atas proses rekayasa persyaratan normal.
2. Pilih anggota kerabat yang paling sesuai. Persyaratan dianalisis dan anggota kerabat yang paling sesuai untuk persyaratan-persyaratan ini dipilih untuk dimodifikasi.
3. Negosiasi ulang persyaratan. Sementara makin banyak muncul detil perubahan yang dibutuhkan bagi sistem yang telah ada dan proyek direncanakan
4. Adaptasi sistem yang sudah ada. Modul-modul baru dikembangkan untuk sistem yang sudah ada dan modul-modul sistem yang telah ada, diadaptasi untuk memenuhi persyaratan-persyaratan baru.
5. Serahkan anggota kerabat yang baru. Anggota kerabat aplikasi yang baru diserahkan kepada pelanggan.
Lankah-Langkah Proses Generik
33
Esilitasi persyaratan stakeholder
Negosiasi ulang persyaratan
Pilih anggota kerabat yang paling sesuai
Serahkan anggota
kerabat baru
Adaptasi sistem yang sudah ada
Pengembangan Anggota Kerabat
34
Pola rancangan (Gamma et al., 1995) diturunkan dari ide yang dikemukakan oleh Christopher Alexander (Alexander et al., 1977), yang mengusulkan bahwa ada pola tertentu pada rancangan pembangunan yang umum dan sekaligus memaskan dan efektif.
'Pola' merupakan deskripsi masalah dan inti solusinya sehingga solusi tersebut dapat dipakai ulang pada setting yang berbeda. Pola ini tidak merupakan spesifikasi yang rinci. Melainkan, Anda dapat menganggapnya sebagai deskripsi dari kebijaksanaan dan pengalaman yang terakumulasi. Pola ini merupakan solusi terhadap masalah umum yang telah diuji dengan baik.
Pola Perancangan
35
Gamma et al. (1995) mendefinisikan empat elemen yang penting pada pola rancangan:
1. Nama yang merupakan referensi yang bermakna terhadap pola.
2. Deskripsi area masalah yang menjelaskan kapan pola tersebut dapat diterapkan.
3. Deskripsi solusi yang mendeskripsikan bagian-bagian solusi perancangan, hu bungannya dan tanggung jawabnya.
4. Pernyataan konsekuensi-hasil dan pertukaran-penerapan pola tersebut. Pernyataan ini digunakan untuk membantu perancang memahami apakah suatu pola dapat diterapkan secara efektif pada suatu situasi tertentu.
Elemen Penting Pola Rancangan