37
Perancangan dengan Pemakaian Ulang Arfianti (092904019) Pendidikan Teknik Informatika dan Komput Universitas Negeri Makassar 2011

Perancangan dengan pemakaian ulang

Embed Size (px)

DESCRIPTION

 

Citation preview

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

13

Komponen

Interface Komponen

Interface requires Interface provides

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

Print

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

36

Pola Observer

37

Terima Kasih ~