PERANCANGAN DENGAN PEMAKAIAN ULANG

Transkripsi

1 PERANCANGAN DENGAN PEMAKAIAN ULANG P T I K REKAYASA PERANGKAT LUNAK (SOFTWARE ENGINEERING)

2

3 Tujuan Memahami keuntungan pemakaian ulang komponenkomponen perangkat lunak dan beberapa masalah pemakaian ulang dapat muncul Memahami berbagai tipe komponen yang dapat dipakai ulang dan proses-proses perancangan komponenkomponen 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

4 Materi Pengembangan Berbasis Komponen Kerabat Aplikasi Pola Perancangan

5 Literatur Sommerville, Ian; Software Engineering, 6th Addison Wesley Publishing Company, 2001

6 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.

7 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.

8 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 komponenkomponen yang relative besar seperti subsistem dipakai ulang.

9 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

10 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.

11 Pendahuluan Pemakaian ulang berbasis generator

12 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.

13 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.

14 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

15 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

16 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

17 Pengembangan Berbasis Komponen Pengembangan Layanan Percetakan

18 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

19 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

20 Pengembangan Berbasis Lanjutan Komponen 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.

21 Pengembangan Berbasis Komponen Pengembangan berorientasi komponen dapat diintegrasikan ke dalam proses pengembangan sistem dengan menggunakan kegiatan pemakaian ulang yang spesifik sebagaimana gambar dibawah ini.

22 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.

23 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.

24 Pengembangan Berbasis Komponen Pengembangan dengan pemakaian ulang

25 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.

26 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.

27 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.

28 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 enduser. Kerangka ini berhubungan dengan kerabat aplikasinya.

29 Kerangka Kerja Aplikasi Kerangka kerja Model View-Controller

30 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.

31 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

32 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

33 Pemakaian Ulang Produk COTS Pada prinsipnya, penggunaan sistem COTS berskala besar sama dengan penggunaan komponen yang lebih khusus lainnya. Namun demikian, kenyataan bahwa produkproduk ini biasanya merupakan sistem besar dan seringkali dijual sebagai sistem yang terpisah dan berdiri sendiri membawa masalah tambahan.

34 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

35 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.

36 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

37 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 dialup date

38 Pengembangan Komponen Lanjutan Untuk Pemakaian Ulang 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.

39 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.

40 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.

41 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.

42 Kerabat Aplikasi Untuk mengilustrasikan pendekatan terhadap pemakaian ulang ini dapat dilihat gambar arsitektur sistem manajemen inventaris.

43 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.

44 Kerabat Aplikasi Dalam implmentasi dari manajemen sumber daya ada pada gambar dibawah ini yaitu sistem perpustakaan

45 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.

46 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.

47 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.

48 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

49 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.

50 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.

51 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.

52 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.

53 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.

54 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.

55 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.

56 Terima Kasih