1. Arfianti (092904019)
Pendidikan Teknik Informatika dan Komputer
Universitas Negeri Makassar
2011
Perancangan dengan Pemakaian
Ulang

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

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

4. Keuntungan
Keuntungan Keterangan
Keandalan Komponen yang dipakai ulang telah diuji pada berbagai lingkungan, sehingga
bertambah komponen tersebut lebih dapat diandalkan daripada komponen baru.
Resiko proses Jika komponen telah ada, ketidakpastian biaya pemakaian ulang menjadi lebih
diperke-cil kecil daripada biaya pengembangan.
Pemakaian spesialis Spesialis aplikasi tidak melakukan pekerjaan yang sama pada berbagai proyek,
yang efektif tapi mereka dapat mengembangkan komponen-komponen yang dipakai ulang,
yang sesuai dengan pengetahuan mereka.
Pemenuhan Pemakaian tampilan antarmuka standar memperbaiki kehandalan, karena
Standar pemakai lebih terbiasa menggunakan tampilan antarmuka yang mereka kenal
sejak lama.
Pengembangan Pemakaian ulang komponen mempercepat proses produksi karena waktu
yang dipercepat pengembangan dan waktu validasi bisa dipersingkat.
4

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

6. Masalah dan Hambatan
Masalah Keterangan
Biaya pengembangan perangkat Jika source code untuk komponen tidak tersedia, maka biaya pemeliharaan
lunak bertambah besar, karena elemen sistem yang dipakai ulang bisa makin tidak
kompatibel dengan perubahan sistem.
Tidak adanya duku-ngan alat Toolset CASE tidak mendukung pengembangan dengan pemakaian ulang.
bantu 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 Memenuhi library komponen dan menjamin pengembang perangkat lunak dapat
komponen memakai library ini mungkin akan mahal. Teknik terbaru untuk klasifikasi,
katalog, dan mengambil komponen perangkat lunak belum matang.
Menemukan dan mengadaptasi Komponen perangkat lunak harus ditemukan pada suatu library, dipahami, dan
komponen perangkat lunak belum diadaptasi untuk bekerja pada lingkungan yang baru.
matang
6

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

8. Pemakaian Ulang Berbasis Generator
8

9. Pemakaian Berbasis Generator yang
Berhasil digunakan
• 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.
9

10. Keuntungan Pandangan Generator
Lebih mudah bagi pemakai untuk
mengembangkan program dengan menggunakan
generator dibandingkan dengan pendekatan
berbasis komponen lainnya terhadap pemakaian
ulang.
10

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

12. Karakteristik Komponen yang dapat
dipakai ulang
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.
12

13. Interface Komponen
Komponen
Interface requires Interface provides
13

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

15. Contoh : Komponen layanan
pencetakan
Print Sevice
Interface requires Interface provides
GetPDfile Print
PrinterInt GetQueue
Remove
Transfer
Register
UnRegister
15

16. Tingkat Abstaksi
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.
16

17. Pengembangan Berorientasi Komponen
Pengembangan berorientasi komponen dapat
diintegrasikan ke dalam proses pengembangan
sistem dengan menggunakan kegiatan pemakaian
ulang yang spesifik
Rancangan Cari komponen
Spesifikasi Pakai komponen
arsitektur yang dapat
Komponen yang ditemukan
sistem dipakai ulang
Proses pemakaian ulang oportunistik
17

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

19. Pengembangan dengan Pemakaian Ulang
Modifikasi
Buat garis besar Cari komponen
persyaratan menurut
persyaratan yang dapat
komponen yang
sistem dipakai ulang
didapat
Rancang sistem
Cari komponen
Perancangan dengan memakai
yang dapat
arsitektural komponen yang
dipakai ulang
dapat dipakai ulang
19

20. Kerangka Kerja Aplikasi
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).
20

21. Kelas Kerangka Kerja
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.
21

22. Kerangka Kerja Model-View-Controller
Lihat message Input user
Status view modifikasi Status kontroler
Metode View Metode kontroler
Query dan Edit model
update
model
Status model
Metode model
22

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

24. Pemakaian Ulang Produk COST
COST, Commercial Off-The-Shelf
Systems merupakan komponen-
komponen dari sistem pemakaian ulang
yang ditawarkan oleh vendor pihak
ketiga.
24

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

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

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

28. Karakteristik Komponen yang Dapat
Dipakai Ulang
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.
28

29. Kerabat Aplikasi
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.
29

30. Kerabat Aplikasi yang dapat Dikembangkan
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.
30

31. Library user access
Add Delete Query Browse Admin Report Issue Return Users
Resource
Screen spec. Report spec.
desc.
Library Holdings Database
Sistem perpustakaan
31

32. Lankah-Langkah Proses Generik
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.
32

33. Pengembangan Anggota Kerabat
Negosiasi ulang
persyaratan
Esilitasi Pilih anggota
persyaratan kerabat yang
stakeholder paling sesuai
Serahkan
Adaptasi sistem
anggota
yang sudah ada
kerabat baru
33

34. Pola Perancangan
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.
34

35. Elemen Penting Pola Rancangan
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.
35

36. Pola Observer
36

37. Terima Kasih ~
37