Rpl 014 - perancangan dengan pemakaian ulang

Perancangan dengan Pemakaian Ulang

Proses perancangan ulang pada sebagian besar disiplinilmu ditekankan pada pemakaian ulang komponen.

Perangkat lunak harus dianggap sebagai suatu aset, danpemakaian ulang aset sangat penting untuk menaikkanpengembangan dari biaya pengembangnya.

Rekayasa perangkat lunak berbasis pemakaian ulangadalah pendekatan terhadap pengembangan yang mencobamemaksimalkan pemakaian perangkat lunak yang ada. Unitperangkat lunak yang dipakai ulang bisa berukuran sangatberbeda.

KELOMPOK 2 2Perancangan dan Pemakaian Ulang

Contoh

• Pemakaian ulang sistem aplikasi, yaitu seluruhsistem aplikasi dapat dipakai ulang denganmenggabungkannya tanpa perubahan dengansistem lain.

• Pemakaian ulang komponen. Komponen subsistematau satu objek tunggal aplikasi dapat dipakaiulang.

• Pemakaian ulang fungsi. Komponen perangkatlunak yang menggunakan satu fungsi (contohnyafungsi matematik) dapat dipakai ulang.


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.


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.KELOMPOK 2 5Perancangan dan Pemakaian Ulang

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.


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.KELOMPOK 2 7Perancangan dan Pemakaian Ulang

Pemakaian Ulang Berbasis Generator


• Generator aplikasi untuk pemetaan bisnis. Inputnyaberupa 4GL atau interaktif seluruhnya dimana penggunamendefinisikan tampilan dan aksi pemrosesan.Outputnya berupa program seperti COBOL atau SQL.

• Generator parser untuk pemrosesan bahasa. Inputnyaberupa Grammar yang mendeskripsikan bahasa danOutputnya berupa parser bahasa.

• Generator kode pada CASE tool. Inputnya berupa desainperangkat lunak, dan Outputnya berupa program yangmengimplementasikan sistem yang dirancang.

Pemakaian Berbasis Generator yang

Berhasil digunakan


Lebih mudah bagi pemakai untuk

mengembangkan program dengan menggunakan

generator dibandingkan dengan pendekatan

berbasis komponen lainnya terhadap pemakaian

ulang.

Keuntungan Pandangan Generator


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


1. Komponen merupakan entitas yang dapatdieksekusi dan independen. Source code tidaktersedia sehingga komponen tidak dikompilasidengan komponen sistem lain.

2. Komponen mengeluarkan interface mereka dansemua interaksi melalui interface tersebut.Interface komponen dinyatakan dalam operasiyang diparameterisasi dan status internalnyatidak pernah diperlihatkan.

Karakteristik Komponen yang dapat

dipakai ulang


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.


Contoh : Komponen layanan

pencetakan

Print Sevice

Print

GetQueue

Remove

Transfer

GetPDfile

PrinterInt

Interface requires Interface provides

UnRegister

Register


Meyer (1999) mengidentifikasi lima tingkat abstraksi:

1. Abstraksi fungsional dimana komponen mengimplementasi satufungsi, misalnya fungsi matematika.

2. Pengelompokan kasual dimana komponen merupakan sekumpulanentitas yang berhubungan longgar (loosely related) yang mungkinberupa deklarasi data, fungsi, dsb.

3. Abstraksi data dimana komponen merepresentasikan abstraksi dataatau kelas perangkat lunak bahasa berorientasi objek.

4. Abstraksi cluster dimana komponen merupakan sekumpulan kelasyang berhubungan yang bekerja sama. Kelas-kelas ini kadang-kadangdinamakan kerangka kerja.

5. Abstraksi sistem dimana komponen merupakan sistem yangsepenuhnya berdiri sendiri.

Tingkat Abstaksi


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


Proses implementasi sistem dengan menggunakankomponen biasanya merupakan proses pembuatanprototipe atau proses pengembangan inkremental.Bahasa pemrograman standar seperti Java dapatdigunakan dengan komponen pada library yangdireferensi dari program. Alternatifnya (dan lebihumum) digunakan bahasa scripting yang khususdirancang untuk integrasi komponen yang dapatdipakai ulang untuk mendukung pengembanganprogram yang cepat.


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


Pemakaian ulang paling baik didukung padaproses pengembangan berorientasi objek melaluiabstraksi yang tidak terlalu detil, yang disebutsebagai kerangka kerja (framework)

Kerangka kerja (atau kerangka kerja aplikasi)merupakan desain subsistem yang terdiri darisekumpulan kelas yang abstrak dan konkret, danberbagai interface di antara mereka (Wirfs-Brockdan Johnson, 1990).

Kerangka Kerja Aplikasi


Fayad dan Schmidt (1997) mengidentifikasi tiga kelas kerangka kerja:

1. Kerangka kerja infrastruktur sistem yang mendukung pengembanganinfrastruktur sistem seperti komunikasi, interface user dan compiler(Schmidt, 1997).

2. Kerangka kerja integrasi middleware (perangkat menengah) yangterdiri dari satu set standar dan kelas objek yang berhubungan yangmendukung komunikasi dan pertukaran informasi komponen.

3. Kerangka kerja aplikasi perusahaan yang berhubungan dengandomain aplikasi yang spesifik seperti sistem telekomunikasi ataufinansial (Baumer et al., 1997).

Kerangka-kerangka kerja ini memiliki pengetahuan domain aplikasi danmendukung pengembangan aplikasi end-user.

Kelas Kerangka Kerja


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


Kerangka kerja ini pada awalnya diusulkan padatahun 1980-an sebagai pendekatan terhadapperancangan GUI yang memungkinkan presentasimultipel dart sebuah objek dan gaya interaksi yangberbeda dengan setiap presentasi ini.

Kerangka kerja MVC mendukung presentasi datadengan cara-cara yang berbeda dan interaksi yangterpisah dengan setiap presentasi ini. Ketika datadimodifikasi melalui salah satu part presentasitersebut, semua presentasi lain di-update.

MVC


COST, Commercial Off-The-Shelf

Systems merupakan komponen-

komponen dari sistem pemakaian ulang

yang ditawarkan oleh vendor pihak

ketiga.

Pemakaian Ulang Produk COST


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


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.

Keuntungan COST


Proses pengembangan komponen yang ideal harusmerupakan proses berbasis pengalaman, di manakomponen pemakaian ulang khusus dibuat darikomponen yang ada yang telah dipakai ulang dengancara yang oportunis. Dengan menggunakanpengetahuan mengenai masalah pemakaian ulang danadaptasi komponen yang dibutuhkan untukmendukung pemakaian ulang, versi komponen yanglebih generik, yang lebih dapat dipakai ulang, dapatdibuat.

Pengembangan Komponen Untuk Pemakaian

Ulang


1. Komponen harus merefleksikan abstraksi domain yangstabil. Abstraksi domain yang stabil merupakan konsepmendasar pada domain aplikasi yang berubah perlahan.

2. Komponen harus menyembunyikan cara statusnyadirepresentasikan dan harus menyediakan operasi yangmemungkinkan status tersebut diakses dan di-update.

3. Komponen harus seindependen mungkin. Idealnya, sebuahkomponen harus berdiri sendiri sehingga komponen tidakmemerlukan komponen lain untuk beroperasi.

4. Semua eksepsi harus merupakan bagian dari interfacekomponen. Komponen tidak boleh menangani eksepsi sendirikarena aplikasi yang berbeda akan memiliki persyaratanyang berbeda untuk penanganan eksepsi.

Karakteristik Komponen yang Dapat

Dipakai Ulang


Salah satu pendekatan yang paling efektif bagipemakaian ulang didasarkan sekitar kerabat aplikasi.Sebuah kerabat aplikasi atau jalur produk merupakan satuset aplikasi yang memiliki arsitektur spesifik domain

Namun demikian, setiap aplikasi khusus merupakanspesialisasi dalam satu hal. Inti umum dari kerabat aplikasidipakai ulang setiap kali dibutuhkan aplikasi bare.Pengembangan barn bisa melibatkan penulisan beberapakomponen tambahan dan adaptasi beberapa komponen padaaplikasi untuk memenuhi permintaan baru.

Kerabat Aplikasi


1. Spesialisasi platform, di mana berbagai versiaplikasi dikembangkan untuk berbagaiplatform.

2. Spesialisasi konfigurasi, di mana berbagai versiaplikasi dibuat untuk menangani berbagaiperanti periferal.

3. Spesialisasi fungsional, di mana berbagai versiaplikasi dibuat untuk pelanggan denganpersyaratan yang berbeda.

Kerabat Aplikasi yang dapat Dikembangkan


Library user access

Library Holdings Database

Resource desc.

Screen spec. Report spec.

Add Delete Query Browse Admin Report Issue Return Users

Sistem perpustakaan


1. Elisitasi persyaratan stakeholder yang didasarkan atas prosesrekayasa persyaratan normal.

2. Pilih anggota kerabat yang paling sesuai. Persyaratan dianalisis dananggota kerabat yang paling sesuai untuk persyaratan-persyaratanini dipilih untuk dimodifikasi.

3. Negosiasi ulang persyaratan. Sementara makin banyak muncul detilperubahan yang dibutuhkan bagi sistem yang telah ada dan proyekdirencanakan

4. Adaptasi sistem yang sudah ada. Modul-modul baru dikembangkanuntuk sistem yang sudah ada dan modul-modul sistem yang telahada, diadaptasi untuk memenuhi persyaratan-persyaratan baru.

5. Serahkan anggota kerabat yang baru. Anggota kerabat aplikasi yangbaru diserahkan kepada pelanggan.

Lankah-Langkah Proses Generik


Esilitasi persyaratan stakeholder

Negosiasi ulang persyaratan

Pilih anggota kerabat yang paling sesuai

Serahkan anggota

kerabat baru

Adaptasi sistem yang sudah ada

Pengembangan Anggota Kerabat


Pola rancangan (Gamma et al., 1995) diturunkan dariide yang dikemukakan oleh Christopher Alexander(Alexander et al., 1977), yang mengusulkan bahwa ada polatertentu pada rancangan pembangunan yang umum dansekaligus memaskan dan efektif.

'Pola' merupakan deskripsi masalah dan inti solusinyasehingga solusi tersebut dapat dipakai ulang pada settingyang berbeda. Pola ini tidak merupakan spesifikasi yangrinci. Melainkan, Anda dapat menganggapnya sebagaideskripsi dari kebijaksanaan dan pengalaman yangterakumulasi. Pola ini merupakan solusi terhadap masalahumum yang telah diuji dengan baik.

Pola Perancangan


Gamma et al. (1995) mendefinisikan empat elemen yang pentingpada pola rancangan:

1. Nama yang merupakan referensi yang bermakna terhadappola.

2. Deskripsi area masalah yang menjelaskan kapan polatersebut dapat diterapkan.

3. Deskripsi solusi yang mendeskripsikan bagian-bagian solusiperancangan, hubungannya dan tanggung jawabnya.

4. Pernyataan konsekuensi-hasil dan pertukaran-penerapanpola tersebut. Pernyataan ini digunakan untuk membantuperancang memahami apakah suatu pola dapat diterapkansecara efektif pada suatu situasi tertentu.

Elemen Penting Pola Rancangan


35RPL | PERANCANGAN PERANGKAT LUNAK

REAL-TIME

Rpl 014 - perancangan dengan pemakaian ulang

Documents

Transcript of Rpl 014 - perancangan dengan pemakaian ulang