Pemakaian Ulang Antarmuka Berbasis
Form: Survey
Oleh
Uung Ungkawa
33212020
Sekolah Teknik Elektro dan Informatika
Institut Teknologi Bandung
1 Pendahuluan
Software reuse (SR) atau pemakaian ulang software adalah proses pembuatan sistem software dari sistem software yang ada ketimbang membuatnya dari awal. Konsep SR pertama kali dicetuskan pada tahun 1968 dalam konferensi NATO oleh Dougles McIlroy. Asalnya
konferensi itu dicanangkan untuk fokus pada Krisis Software (software crisis); yang diartikan sebagai masalah yang dijumpai dalam pengembangan software yang besar dan handal dengan cara yang efektif. Dalam konferensi itu disampaikan suatu laporan cikal bakal SR: Mass Produced Components oleh Dougles McIlroy dari Bell Laboratories. Dia mengusulkan Pustaka komponen Software atau juga disebut sebagai Pustaka Pemakaian Ulang Software yang dapat dipakai berulang-ulang dan teknik otomatis untuk menyesuaikan (customized) komponen sampai pada tingkat ketepatan dan keandalan tertentu. McIlroy merasa bahwa pustaka komponen dapat diterapkan sacara efektif pada komputasi numerik, konversi i/o pengolahan teks dan alokasi penyimpanan (storage) secara dinamik [1].
Umumnya kakas dan sistem yang dikembangkan untuk SR hanya menyediakan bantuan dalam memungut (retrieve) entitas software seperti kelas-kelas, fungsi dan spesifikasi dari repositori (tempat penyimpanan pustaka). Sebenarnya SR juga membutuhkan adaptasi pengetahuan yang didapat untuk sistem yang sedang dikembangkan, yang biasanya dilakukan sepenuhnya oleh disainer karena memang ini pekerjaan yang rumit dan membutuhkan banyak hal untuk dipertimbangkan. Penalaran analogi (analogical reasoning) tampil sebagai teknik yang dapat digunakan untuk mengatasi beberapa masalah adaptasi dari SR, karena hal ini melibatkan alih gagasan dan solusi dari satu bidang ke bidang lainnya. Ini tidak hanya memberikan jalan keluar untuk mendapatkan solusi tetapi juga memberikan peluang untuk membentuk solusi baru dan kadang solusi yang kreatif. Ini juga dapat memberikan gagasan dan pilihan terhadap disainer yang membantu untuk mengeksplorasi ruang solusi dengan cara yang lebih baik [4].
bahasa pemodelan antarmuka atau lebih dikenal sebagai bahasa spesifikasi atau bahasa deskripsi.
2 Software Reuse (SR)
Hampir 20 tahun kemudian setelah ide SR muncul, ilmuwan komputer masih memandang pemakaian ulang software sebagai cara potensial yang ampuh untuk meningkatkan
pelaksanaan rekayasa software. Keuntungan yang makin nyata terhadap usaha pengembangan software melalui pemakaian ulang makin mendapat pengkauan meskipun kakas (tool), metoda, bahasa dan pemahaman menyeluruh terhadap rekayasa software telah banyak berubah sejak 1968. Di samping menjanjikan, SR belum berhasil menjadi standar penerapan dalam pembangunan software. Melihat kegagalan ini, masyarakat ilmuwan komputer telah memperbaharui ketertarikannya terhadap pemahaman bagaimana dan di mana pemakaian ulang bisa efektif dan mengapa terbukti sulit membawa gagasan yang tampak sederhana ini ke ranah teknologi pengembangan software [1].
Krueger [1] melakukan survey tentang SR dari empat dimensi yakni abstraksi, seleksi, spesialisasi dan integrasi. Abstraksi suatu artifak software adalah deskripsi ringkas yang menyampingkan rincian yang kurang penting kepada pengembang software dan menonjolkan informasi yang penting.
Dalam menentukan efektifitas penerapan SR, Krueger mendefinisikan konsep jarak kognisi (cognitive distance) yakni jumlah usaha intelektual yang harus dibayarkan oleh pengembang software untuk membawa sistem software dari satu tahapan pengembangan ke tahapan lainnya. Jarak kognitif ini bukn ukuran formal yang dapat dinyatakan dengan angka dan satuan, tetapi merupakan gagasan informal berdasarkan intuisi berkenaan dengan usaha relatif yang diperlukan untuk melaksanakan berbagai tugas pengembangan software. Bagi yang menerapkan SR, tujuannya adalah untuk meminimalkan jarak kognisi melalui:
1. Menerapkan abstraksi yang tetap dan variabel yang ringkas dan jelas (ekspresif) 2. Memaksimalkan bagian yang tersembunyi dari abstraksi
3. Menggunakan pemetaan otomatis dari abstraksi spesifikasi ke abstraksi realisasi
Meskipun Krueger mengemukakan SR dalam pemulungan disain dan kode program, namun sedikit sekali membicarakan disain. Umumnya programer mengadopsi SR dalam pemulungan disain dan kode dilakukan secara ad hoc, tidak sistematis, meskipun memang efektif. Mereka mendapat fragmen kode dari sistem yang ada dan menggunakannya sebagai bagian dari pengembangan sistem yang baru. Pengembang yang berpengalaman diketahui banyak mendapatkan manfaat dari pemakaian ulang disain. Tujuan dari pemungutan disain dan kode adalah untuk mengurangi usaha kognitif, jumlah tombol yang ditekan dan tentunya jumlah waktu yang diperlukan untuk disain, implmentasi dan debug sistem software yang baru. Pemulung menyalin sebanyak-banyaknya dari sistem yang mirip yang telah didisain, diimplementasikan dan didebug sebelumnya.
2.1 Keuntungan dan Kerugian SR
Kaur dan Goyal [7] mencatat beberapa keuntungan dan kerugian SR. Keuntungannya adalah:
- Meningkatkan Keandalan: SR menyebabkan komponen SR terus diuji lagi dan lagi yang akan mengurangi dijumpainya error dan meningkatkan keandalan komponen, karena makin sering dipakai, makin sering diuji dan peluang dijumpai error lagi akan makin kecil.
- Mengurangi Resiko Proses: Jika software sudah ada, maka sedikit ketidakpastian biaya dalam penggunaan ulang software tersebut ketimbang biaya untuk
pengembangan. Ini merupakan faktor penting dalam manajemen proyek karena mengurangi margin kesalahan dalam estimasi biaya proyek. Terlebih lagi jika software yang dipakai ulang merupakan software besar (sub sistem).
- Pemanfaatan Spesialis yang Efektif: Orang yang berpengalaman atau spesialis efektif dalam pengembangan sistem software. Karena pengalamannya, dia tahu komponen mana yang bisa dipakai lagi.
- Percepatan dalam Pengembangan: SR jelas meningkatkan produktifitas, karena komponen yang sudah dibuat dapat digunakan selagi pengembangan sistem baru. Ini akan mengurangi waktu dan biaya pengembangan.
Sedangkan kerugiannya adalah:
yang reusable, semua aplikasi menyajikan format menu yang sama ke pengguna. Memang, keandalan meningkat karena bagi pengguna akan lebih kecil kemungkinan keliru apabila disajikan menu yang sudah dikenal.
- Perlu Dokumentasi yang Baik: Karena selama pengembangan komponen SR memerlukan dokumentasi penuh, sehingga orang lain yang tidak terlibat mengerti cara kerja komponen dengan lebih mudah. Akan tetapi jika dokumentasi kurang baik, maka akan rumit untuk difahami.
- Membuat dan Memelihara Pustaka Komponen: Membuat dan memelihara pustaka SR menjadi mahal karena pemeliharaan membutuhkan beberapa orang ahli dan juga teknik untuk mengklasifikasi, mengkatalog dan memungut kembali komponen masih belum matang. Demikian pula jika ada pengembang yang kurang berpengalaman maka hasilnya akan terbalik karena kurang mengerti sistem software.
- Mendapatkan, Memahami dan Adaptasi Komponen: Komponen harus ditemukan dalam pustaka, difahami dan kadang disesuaikan (adaptasi) agar bisa jalan di sistem yang baru. Insinyur harus bertanggung jawab menemukan komponen dalam pustaka sebelum melakukan pencarian rutin.
2.2 Proses Software Reuse
Almeida et al [5] melakukan survey berkaitan dengan proses software reuse. Mereka mengidentifikasi 2 proses: domain engineering proses dan product line process. Domain engineering adalah aktifitas mengumpulkan, mengorganisasi dan menyimpan pengalaman masa lalu dalam membangun sistem atau bagian sistem dalam domain tertentu dalam bentuk aset yang dapat dipakai ulang, juga menyediakan perlengkapan yang cukup untuk memakai ulang aset tersebut ketika membangun sistem baru.
Almeida mengemukakan perkembangan penerapan pendekatan SR. Awal 80an dan 90an, beberapa usaha dalam pemakaian ulang berfokus pada domain engineering seperti Draco (Neighbors) [6], yang berbasis pada teknologi transformasi. Gagasan utama yang
diperkenalkan dalam Draco adalah domain analysis, domain specific language dan komponen sebgai sekumpulan transformasi. Usaha Neighbors memberi kontribusi penting dalam bidang domain engineering, memberikan konsep seperti pemrograman generative, sistem
dalam lingkungan industri karena kerumitan untuk melakukan aktifitas seperti membuat transformasi dan menggunakan sistem Draco itu sendiri [5].
Dalam kaitan ini, pada 1992 Software Technology Adaptable, Reliable Systems (STARS) mengembangkan the Conceptual Framework for Reuse Processes (CFRP) sebagai sarana untuk memahami dan menerapkan paradigma rekayasa software berbasis reuse dan domain-specific karya STARS. CFRP membangun framework yang menangani proses rekayasa software berbasis reuse, bagaimana interrelasinya, bagaimana hal itu dipadukan satu sama lain dan juga dengan proses yang bukan berbasis reuse untuk membentuk model proses berorientasi reuse yang dapat disesuaikan dengan kebutuhan organisasi.
Akan tetapi, FRP itu sendiri merupakan framework yang generik dan organisasi yang telah menerapkannya merasakan bahwa CFRP terlalu generik untuk sekadar melayani penyesuaian untuk membangun model siklus hidup rekayasa software berbasis reuse dan domain spesific. Karena itu, dibangunlah ROSE PM dari team Paramax STARS yang secara khusus
menjembatani kesenjangan antara framework yang generik dan high-level dengan metode yang rinci dan prskriptif.
Almeida terus menelusuri perkembangan penerapan SR berbasis domain-engineering dengan berbagai masalah dan solusinya sampai pada ODM (Organization Domain Modelling), RSEB (Reuse-driven Software Engineering Business), FeatuRSEB dan FORM (Featur Oriented Reuse Method).
Selanjutnya menurut Almeida, hingga 1998, proses SR hanya berkaitan dengan masalah domain engineering. Akan tetapi, dalam rentang waktu yang sama, mulailah ditekuni tren baru: bidang software product line (SPL). SPL dipandang sebagai kemajuan yang
menjanjikan dalam pengembangan software yang efisien. Akan tetapi, hingga akhir 90an hanya ada beberapa panduan atau metodologi untuk membangun dan menerapkan product-line yang melampaui pendekatan domain engineering yang ada. Di pihak lain, pendekatan domain engineering tidak terbukti efektif seperti yang diharapkan.
2.3 Pendekatan-Pendekatan Software Reuse
Prieto-Diaz [8] mengidentifikasi pendekatan-pendekatan SR melalui 6 dimensi/perspektif yang disebut facet: substance, scope, mode, technique, intention dan by-product seperti pada tabel di bawah:
{by-substance} {by-technique}
ideas, concepts vertical planned, systematic
compositional as-is, black box source code
artifacts,
components horizontal ad-hoc, opportunistic generative with-modification,white box design
procedures, skills specifications
objects
text
architectures
Menurut Lucredio et al [9], ada tiga pendekatan utama dalam SR: Component-Based Development (CBD), Domain Engineering (DE) dan Software Product Line (SPL).
Ketiganya merupakan perkembangan SR yang bergerak menuju cara yang lebih sistematik untuk mempromosikan SR. Kebanyakan pendekatan SR berdasar pada CBD yang merupakan gagasan lama. Pada tahun 1968, McIlroy menggagas bahwa sistem software harus
mengabstraksikan yang umum ada (common) pada kebanyakan komponen. Proses ini menjadi dasar pendekatan yang disebut Domain Engineering (DE).
DE terdiri dari pengumpulan, pengorganisasian dan penyimpanan pengalaman selama membangun sistem domain tertentu dalam bentuk aset yang dapat dipakai ulang dan
memberikan cara pemakaian ulang yang cukup terhadap aset ini dalam pengembangan sistem yang baru. Akan tetapi pendekatan DE ini ternyata tidak seefisien yang diharapkan. Maslah utamanya adalah bahwa domain mencakup beberapa unsur yang tidak penting bagi
organisasi/instansi sehingga memaksa untuk mengimplementasikan beberapa komponen yang tudak berguna ketimbang fokus hanya pada produknya. Untuk memecahkan hal ini, trend baru mulai didekati: Software Product Line (SPL). Perbedaannya dengan DE adalah
berkaitan dengan cakupan domain: ketimbang memperhatikan semua aplikasi yang mungkin ketika membangun komponen, SPL lebih fokus pada produk (eksistensi, dalam
pengembangan dan perencanaan), sehingga domain hanya terdiri dari unsur yang penting bagi instansi. Titik-titik perbedaan antara aplikasi diketahui dengan baik, sehingga
pengembang bisa memilih di antara kombinasi fitur yang mungkin yang akan dipakai dalam produk.
Nath dan Kumar [11] menambahkan pendekatan architectur-based dalam SR. Dalam hal ini mereka mengutip pandangan Mary Shaw [12]: pemakaian ulang yang efektif tidak hanya bergantung pada cara mendapatkan dan menggunakan kembali komponen, tetapi juga pada cara bagaimana komponen itu diramu. Arsitektur sistem software terdiri dari komponen software, sifat-sifat eksternal dan hubungannya satu sama lain. Pemakaian ulang berbasis arsitektur ini memperlebar definisi aset yang dapat dipakai ulang untuk menyertakan sifat-sifat dan hubungan antar komponen.
Shaw melakukan klasifikasi arsitektur berdasarkan 4 unsur tama: komponen, konektor, struktur kontrol dan model sistem. Sistem terdiri dari berbagai jenis komponen yang dapat diidentifikasi. Komponen-komponen ini berinteraksi dengan cara berbeda dan dapat dikenali. Komponen berkaitan dengan satuan kompilasi dalam pengertian bahasa pemrograman
konvensional, hingga objek bertaraf pengguna seperti berkas. Sedangkan konektor menjadi perantara interaksi antar komponen; yang tunduk pada cara interaksi dan mekanisme yang diharuskan. Konektor tidak secara langsung berkaitan dengan satuan kompilasi tetapi menjelma sebagai tabel entri, perintah ke linker, struktur data dinamik, pemanggilan sistem, inisialisasi parameter, dan sebagainya. Struktur kontrol merupakan aturan aksekusi. Model sistem menggambarkan bagaimana semuanya dipadu.
Dusink [13] mengidentifikasi beberapa penelitian SR yang disebut sebagai pendekatan SR [14]:
- Pemakaian ulang transformasional (kadang disebut generatif) dibanding kompositional. Dalam sistem transformasional, hasil diperoleh melalui transformsi dari spesifikasi tingkat tinggi sistem yang diinginkan. Dalam pendekatan komposisional, pemilihan dan komposisi komponen dilakukan orang.
- Pemakaian white box dibanding black box. Dalam pendekatan black box, produk yang diapakai ulang dipakai apa adanya, sementara dalam pendekatan white box, produk dimodifikasi dan diadaptasi terhadap aplikasi tertentu.
- Tingkat abstraksi: pemakaian ulang dapat diterapkan pada tingkat kode, disain, pengujian, rekuiremen, dsb, meskipun kebanyakan pada tingkat kode.
- Produk dibanding proses: Apakah hanya produk yang dipakai ulang atau pengetahuan mengapa dan bagaimana melakukan sesuatu cara, juga dipakai ulang?
- Horisontal dan vertikal: vertikal terjadi dalam bidang atau domain aplikasi yang sama sementara horisontal berarti bagian yang dipakai ulang dari satu bidang aplikasi digunakan untuk bidang yang berbeda.
3 Case-Based Reasoning
Case-Based Reasoning (CBR) adalah metodologi untuk menyelesaikan masalah dengan menggunakan pengalaman yang lampau. CBR menyimpan masalah dan solusinya dan dengan mengacunya, menyelesaikan masalah baru. Masalah dan solusinya yang tersimpan itu disebut kasus (case). Ketika dihadapkan pada maslah baru, sistem CBR mencari kasus dalam memorinya (case-base) dan mencari kasus dengan masalah yang sama dengan masalah yang sekarang (target). Jika tidak ada masalah yang sama, berusaha mencari masalah yang paling mirip. Jika ditemukan masalah yang sama maka solusinya langsung diberikan tetapi jika hanya mirip, maka dilakukan adaptasi terhadap solusi yang didapat, sebelum solusi itu diberikan. Dalam melakukan adaptasi, pertama diidentifikasi dulu perbedaan kasusnya, kemudian adaptasi dilakukan sesuai perbedaan itu. Setelah adaptasi, baru solusi tersebut dicoba untuk diberikan. Jika diterima, sistem CBR bisa menyimpan masalah dan solusi yang baru sebagai kasus baru. Jika solusi belum final, bisa terjadi adaptasi ulang.
Proses-proses yang merangkai penalaran berbasis kasus dapat dipandang cerminan salah satu jenis penalaran manusia. Dalam banyak situasi, masalah yang dihadapi manusia dipecahkan manusia seperti CBR. Jika seseorang menjumpai situasi atau persoalan yang belum dialami sebelmnya, dia seringkali mengacu ke persoalan serupa yang dialami sebelumnya. Persoalan serupa ini bisa pengalaman dia sendiri atau pengalaman orang lain, kasus ditambahkan dalam ingatan penalaran manusia melalui lisan atau tulisan.
3.1 Kapan menggunakan CBR?
Ada sejumlah karakteristik persoalan dan domainnya yang dapat digunakan untuk menentukan apakah CBR bisa diterapkan [15]:
1. Apakah domain memiliki model?
Jika proses penalaran bersifat acak, atau jika faktor yang membawa keberhasilan atau
2. Adakah pengecualian dan kasus baru?
Domain yang tidak memiliki kasus yang baru atau pengecualian, lebih baik dimodelkan dengan aturan (rule-based), yang dapat ditentukan secara induktif dari sejumlah kasus.
3. Apakah kasusnya berulang?
Apabila suatu kasus tidak mungkin dipakai dalam persoalan berikutnya, karena kurangnya kemiripan, maka kecil, jika ada, nilainya dalam menyimpan kasus tersebut. Dalam domain demikian, jika kasus tidak cukup mirip, untuk diadaptasi, maka mungkin lebih baik
membangun model proses membentuk solusi, ketimbang model untuk domain solusi.
4. Adakah keuntungan yang berarti dalam adaptasi solusi yang lampau?
Kita harus perhatikan apakah ada perbedaan yang berarti dalam sumberdaya yang
dikeluarkan (waktu, proses, dsb) antara menciptakan suatu solusi terhadap persoalan dari awal dan menciptakan solusi dengan mengubah solusi yang mirip?
5. Apakah kasus sebelumnya yang relevan bisa didapat?
Apakah mungkin untuk mendapatkan data yang merekam karakteristik yang penting kasus-kasus yang lampau? Apakah kasus-kasus yang terekam mengandung fitur-fitur persoalan dan konteknya, mempengaruhi outcome dari solusi? Apakah solusi yang terekam secara rinci perlu untuk diadaptasi di masa datang?
Jika jawabannya kebanyakan positif, maka mungkin CBR bisa diterapkan dan relevan.
3.2 Mengapa Menggunakan CBR?
Jika digunakan dalam situasi yang tepat, CBR menawarkan banyak keuntungggan. Dalam sub bab dirangkum beberapa di antaranya [15].
Pengurangan tugas akuisisi pengetahuan.
Dengan menghilangkan ekstraksi model atau sekumpulan aturan sebagaimana ada dalam model sistem berbasis aturan, maka tugas akuisisi pengetahuan terutama hanya terdiri dari sekumpulan kasus/pengalaman yang lampau dan relevan, dan representasinya serta
penyimpanannya.
Dalam sistem yang merekam kegagalan dan keberhasilan, dan mungkin alasan kegagalannya, sistem dapat menggunakan informasi tentang apa penyebab kegagalan di masa lampau untuk memperkirakan kegagalan di masa depan.
Penurunan sedikit unjuk kerja
Beberapa sistem berbasis model bahkan tidak dapat menyelesaikan persoalan pada batas-batas cakupan pengetahuan, atau bila ada data yang tidak lengkap. Sebaliknya, sistem CBR seringkali berhasil menyelesaikan persoalan seperti ini.
Mampu melakukan penalaran dalam domain yang tidak sepenuhnya difahami, didefinisikan dan dimodelkan
Sementara dalam sistem berbasis model kadang dijumpai kekurangan pengetahuan tentang domain atau juga kesulitan model heuristiknya, sistem CBR bisa bekerja dengan sedikit kasus yang dimilikinya.
Mampu memperkirakan peluang keberhasilan solusi yang diutamakan.
Karena informasi disimpan sesuai tingkat keberhasilannya di masa lalu, CBR mampu memperkirakan keberhasilan solusi yang disarankan. Ini bisa dilakukan dengan mengacu solusi yang tersimpan dan perbedaan kontek antara solusi yang ada dengan solusi yang baru.
Belajar sepanjang waktu.
Ketika dipakai, sistem CBR menjumpai lebih banyak situasi dan menciptakan banyak solusi. Jika kasus diuji di lapangan dan tingkat keberhasilannya ditentukan, kasus ini dapat
ditambahkan ke dalam basis kasus untuk dapat digunakan di masa datang. Begitu kita tambahkan kasus baru, sistem dapat melakukan penalaran dalam situasi yang lebih luas dan dalam tingkat keberhasilan yang lebih tinggi.
Menalar dalam domain yang sedikit pengetahuan.
Sementara dalam domain yang sedikit dikenal, dan sedikit kasus yang dimiliki, CBR dapat mulai bekerja dengan sedikit kasus dan secara bertahap meningkat pengetahuannya begitu kasus bertambah. Penambahan kasus ini juga akan menyebabkan sistem tumbuh dengan arah sesuai dengan persoalan yang dijumpai.
Karena kasus yang diambil tidak hanya yang sama tetapi juga yang mirip, ketidaklengkapan atau ketidaktepatan dapat diatasinya. Sementara faktor ini dapat menyebabkan penurunan unjuk kerja akibat perbedaan kasus, penalaran masih tetap bisa berjalan.
Menghindari langkah yang sama yang diperlukan dalam meraih solusi
Dalam domain yang memerlukan proses yang penting untuk menciptakan solusi dari awal, modifikasi solusi sebelumnya dapat mengurangi proses secara signifikan. Dengan memakai ulang solusi sebelumnya, langkah yang diambil untuk mendapatkan solusi dapat juga dipakai ulang.
Memberi cara untuk penjelasan
CBR dapat memberikan kasus yang lalu dan solusinya yang berhasil, untuk meyakinkan pengguna atau mendapat justifikasi pengguna terhadap solusi yang diberikan. Dalam kebanyakan domain, ada saatnya pengguna ingin diyakinkan kualitas solusi yang diberikannya. Dengan menjelaskan bagaimana kasus sebelumnya sukses dalam situasi tertentu, melalui kemiripan antar kasus dan penalarannya, sistem dapat menjelaskan ke pengguna.
Dapat digunakan dalam cara berbeda.
Berapa cara sistem CBR dapat diimplementasikan hampir tidak terbatas. CBR dapat digunakan untu banyak keperluan: untuk perencanaan, melakukan diagnosa, memberi argumentasi suatu pandangan, dsb. Sebagaimana data bisa mengalami banyak bentuk, begitu juga metode pungut ulang (retrieval) dan adaptasinya. Sepanjang kasus yang lampau bisa dipungut ulang dan diadaptasi, penalaran bisa terus berlangsung.
Dapat diterapkan untuk berbagai jangkauan domain yang luas
CBR memiliki banyak bidang aplikasi. Karena cara representasi, indexing, pemungutan ulang dan adaptasi kasus tidak terbatas, CBR dapat diterapkan pada domain aplikasi yang sangat beragam.
Mencerminkan penalaran manusia.
Makin kritis domainnya, makin rendah peluang untuk digunakan, makin tinggi tingkat pemahaman pengguna, dan merasa yakin memerlukannya.
3.3 Bidang Terapan CBR
Bidang terapan CBR sangat luas dan sudah banyak penelitian untuk tiap bidang terapan dimaksud. Beberapa bidang terapan di bawah ini diambil dari [15]:
- Hukum
- Kedokteran
- Rekayasa
- Help desk
- Jaringan komunikasi
- Disain manufaktur
- Keuangan
- Penjadwalan pengerjaan (job shop)
- Penjadwalan
- Bahasa
- Penjelasan dan pemahaman cerita
- Makanan (membuat resep)
- Mencari rute
- Penanganan material untuk perakitan
- Kebutuhan telepon (memperkirakan kebutuhan)
- Lingkungan (tingkat pencemaran)
- Diagnosa kesalahan sistem
3.4 Penerapan CBR dalam SR
CBR dan SR memiliki karakteristik yang sejajar dan mirip. Dalam CBR ada proses, reuse dan adaptasi demikian pula dalam SR, sehingga penerapan CBR dalam SR menjadi tepat. Lebih lanjut kemiripan itu dapat dilihat dalam tabel berikut [16].
CBR Compositional SR Persoalan input dikarakterisasi dengan cara
memberi fitur-fitur yang cocok
Mendapatkan spesifikasi fungsional dari komponen
Memungut kasus dari memori dengan fitur yang cocok
Mencari dalam pustaka komponen untuk mendapatkan calon yang memenuhi spesifikasi
Mengambil kasus atau beberapa kasus yang paling cocok
Pakai ulang komponen yang memenuhi spesifikasi atau merangking beberapa calon yang paling memenuhi
Mengadaptasi solusi kasus yang paling cocok untuk menyesuaikan dengan persoalan
Memilih calon yang paling mudah untuk dipakai ulang dan diadaptasi
Pada mulanya code program sebagai komponen yang pakai ulang seperti pada sistem Caesar (Case Based Software Reuse System) [16, 17]. Tujuan Caesar adalah untuk membantu pengguna untuk program baru dari spesifikasinya. Sasarannya bukan harus memenuhi spesifikasi, tidak dimaksudkan sebagai sistem sintesis program, tetapi untuk membuat program yang berguna bagi pengguna sebagai program awal (draft). Peranan pengguna Caesar karenanya tidak dibatasi pada penyediaan spesifikasi tetapi biasanya terlibat dalam memodofikasi program yang dibangun. Untuk itu Caesar perlu memberikan beberapa penjelasan tentang program yang dibangun.
Program (komponen) terlebih dahulu dianalisis aliran datanya (data flow) dan ditrnasformasi untuk bisa disimpan dalam basis kasus. Analisis menghasilkan fungsi kode untuk dijadikan indeks kasus. Caesar menggunakan graf cause-effect untuk pengujian dan evaluasi fungsi yang dibangkitkan.
Secara sintaks, spesifikasi kode berupa formula konjungsi dalam FOL (first order logic). Ini berfungsi sebagai deskripsi fungsi program, identifikasi input, output dan sifat-sifatnya (karakteristik dan batasn tiap input dan output) dan relasi antara input dan output (perilaku program). Caesar dikembangkan untuk kode prosedural (seperti fungsi matematik) dan bukan untuk kode berorientasi objek.
Sistem lain yang memakai ulang dalam fase koding adalah Deja Vu [18] yang
Gonzalez dan Fernandez [19, 20] menerapkan pendekatan CBR untuk pemakaian ulang kode berorientasi objek. Mereka menggabungkan CBR dengan DL (description logic) untuk penalarannya. Kasus merepresentasikan tiga jenis entitas: kelas, metode dan resep
pemrograman sehingga memungkinkan memungut ulang ketiga jenis objek ini. Kasus terdiri dari persoalan(deskripsi leksikal), solusi (kode) dan justifikasi (sifat kode). Di sini digunakan LOOM, suatu bahasa deskripsi konseptual untuk representasi sifat kode.
Tautz dan Althoff [21] melakukan pendekatan yang berbeda dalam SR. Ketimbang memakai ulang kode, mereka memakai ulang rekuiremen sistem dan pengetahuan dalam
pengembangan. Pendekatan ini merupakan salah satu pendekatan yang menangani semua fase pengembangan software. Pemakaian ulang dapat diterapkan baik pada perencanaan projek pengembangan software sampai pada unjuk kerja projek.
Gomes menerapkan CBR dalam pemakaian ulang design [4].
4 Specification Language
Bahasa Spesifikasi
aecXML
UIML
UsiXML
XIML
Teresa
UMLi
UIDLs Overview
DISL
Dialog and Interface Specification Language (DISL) [Error: Reference source not found] is a user interface markup language (UIML) subset that extends the language in order to enable generic and modality independent dialog descriptions. Modifications to UIML mainly concerned the description of generic widgets and improvements to the behavioral aspects. Generic widgets are introduced in order to separate the presentation from the structure and behavior, i.e., mainly to separate user- and device-specific properties and modalities from a modalityindependent
presentation. The use of generic widget attribute enables to assign each widget to a particular type of functionality it ensures (e.g., command, variable field, text field, etc.). Further, a DISL rendering engine can use this information to create interface components appropriated to the interaction modality (i.e., graphical, vocal) in which the widget will operate. The global DISL structure consists of an optional head element for Meta information and a collection of templates and interfaces from which one interface is considered to be active at one time. Interfaces are used to describe the dialog structure, style, and behavior, whereas templates only describe structure and style in order to be reusable by other dialog components.
GIML
The Generalized Interface Markup Language (GIML) is used for the generalized Interface Toolkit (GITK) [Error: Reference source not found]. GIML is used in this context as an interface descriptor.
Following the OMG principles of separation of concerns GIML splits functionality and presentation. While the functionality is preserved in GIML the UI is derived from
ISML
Interface Specification Meta-Language (ISML) [Error: Reference source not found] was developed with the intention that methaphors (shared concepts between the user and the computer) be made explicit in design. ISML de-couples that metaphor model from any particular implementation, and express mappings between the concepts shared between the user and the system. It provides a framework that supports mappings between both user-oriented models (such a task descriptions) and software architecture concerns (interactor definitions). The ISML framework composites these concepts within five layers (devices, components, meta-objects, metaphor, interactors), using a variety of mappings to link them together.
RIML
Renderer-Independent Markup Language (RIML) [Error: Reference source not found] is a markup language based on W3C standards that allows document authoring in a device independent fashion. RIML is based on standards such as: XHMTL 2.0 and XFORMS. Special row and column structures are used in RIML to specify content adaptation. Their semantics is enhanced to cover pagination and layout directives in case pagination needs to be done. Due to the use of XForms, RIML is device independent and can be mapped into a XHTML specification according to the target device. RIML semantics is enhanced to cover pagination and layout directives in case pagination needs to be done, in this sense it was possible to specify how to display a sequence of elements of the UI.
SeescoaXML
Software Engineering for Embedded Systems using a Component-Oriented Approach (SeescoaXML) [Error: Reference source not found] consists of a suite of models and a
mechanism to automatically produce different final UIs at runtime for different computing platforms, possibly equipped with different input/output devices offering various modalities (e.g. a joystick). This system is context-sensitive as it is expressed first in a modality-independent way, and then connected to a
to a high-level description of input/output devices. The entry point of this forward engineering approach is therefore located at the level of Abstract UIs.
SunML
Simple Unified Natural Markup Language (SunML) [Error: Reference source not found] is an XML language to specify concrete user interfaces that can be mapped to different devices (PC, PDA, voice). The innovation of this language is the capacity to specify dynamically components. In SunML it is also possible to encapsulate the style and the content of each widget independent of the others. Two different files are used for that purpose. Another interesting feature offered in SunML is widget
composition. Some operators have been defined for that purpose: union (semantically-common widgets), intersection, subtraction, substitution, inclusion. Widgets Merging Language (WML) is the extension used for that purpose. SunML presents a reduced set of elements that seems to be not enough, but the composition of widgets is used to specify more complex widgets.
TeresaXML
UIML
User Interface Markup Language (UIML) [Error: Reference source not found] is an XML-based language that provides: (1) a device-independent method to describe a UI, (2) a modality-independent method to specify a UI. UIML allows describing the appearance, the interaction and the connection of the UI with the application logic. The following concepts underlie UIML:
1. UIML is a meta-language: UIML defines a small set of tags (e.g., used to describe a part of a UI) that are modality-independent, target platform-independent (e.g., PC, phone) and target language-independent (e.g., Java, VoiceXML). The specification of a UI is done through a toolkit vocabulary that specifies a set of classes of parts and properties of the classes. Different groups of people can define different vocabularies: one group might define a vocabulary whose classes have a 1-to-1 correspondence to UI widgets in a particular language (e.g., Java Swing API), whereas another group might define a vocabulary whose classes match abstractions used by a UI designer
2. UIML separates the elements of a UI and identifies: (a) which parts are composing the UI and the presentation style, (b) the content of each part (e.g., text, sounds, images) and binding of content to external resources, (c) the behavior of parts expressed as a set of rules with conditions and actions and (d) the definition of the vocabulary of part classes.
3. UIML groups logically the UI in a tree of UI parts that changes over the lifetime of the interface. During the lifetime of a UI the initial tree of parts may dynamically change shape by adding or deleting parts. UIML provides elements to describe the initial tree structure and to dynamically modify the structure.
4. UIML allows UI parts and part-trees to be packaged in templates: these templates may then be reused in various interface designs.
UsiXML
USer Interface eXtensible Markup Language (UsiXML) [Error: Reference source not found] is structured according to different levels of abstraction defined by the Cameleon reference framework [Error: Reference source not found]. The framework represents a reference for classifying UIs supporting a target platform and a context of use, and enables to structure the development life cycle into four levels of abstraction: task and concepts, abstract UI (AUI), concrete UI (CUI) and final UI (FUI). Thus, the Task and Concepts level is computational-independent, the AUI level is modality-independent (In the cockpit it can be several physical, Vocal, GUI, Tactile) and the CUI level is toolkitindependent. UsiXML relies on a
transformational approach that progressively moves among levels to the FUI. The transformational methodology of UsiXML allows the modification of the
underlying abstract formalism represented under the form of a graph-based syntax.
WSXL
Web Service eXperience Language (WSXL) [Error: Reference source not found] [Error: Reference source not found] is designed to represent data, presentation and control. WSXL relies on existing standards; in particular, XML based standards such as XPath, XML Events, DOM, XForms and XLink as well as Web Services standards such as SOAP, WSDL and WSFL. WSXL includes an extensible Adaptation Description Language where explicit locations of adaptation points, the permissible
operations on adaptation points (e.g. insert, delete, modify), and the constraints on the contents of adaptation (e.g. via an XML Schema) can be specified. The Adaptation Description Language can be used during a post-processing step where the output of a WSXL component can be adapted independently without invoking the component. Finally, a WSXL collection provides an execution and management environment for WSXL components. It calls the lifecycle operations on WSXL components it instantiates, and implements a set of interfaces and a processing model for use by WSXL components and objects external to the collection. An object implementing the WSXL collection interface need not be a WSXL component. The developer can create new and more abstract UI
components.
XICL
The eXtensible user-Interface Markup Language (XICL) [Error: Reference source not found] is an easy way to develop User Interface Components to Browser-based software. New UI components are created from HTML components and others XICL components. The XICL description is translated into DHTML code. An XICL documents is
composed by a UI description composed by HTML or XICL elements and several components (Structure, Properties, Events and Methods. XICL is a language to UI development by specifying its structure and behavior in an abstract level than using only DHTML. It also promotes reuse and extensibility of user interface components.
XIML
derived from XML and able to store the models developed in MIMIC [Error: Reference source not found]. MIMIC is a meta-language that structures and organizes interface models. It divides the interface into model components: user-task, presentation, domain, dialog, user, and design models. The design model contains all the mappings between elements belonging to the other models. The XIML is thus the updated XML version of this previous language. The XIML language is mainly composed of four types of components: models, elements, attributes, and relations between the elements. The presentation model is composed of several embedded elements, which correspond to the widgets of the UI, and attributes of these elements representing their characteristics (color, size…). The relations at the presentation level are mainly the links between labels and the widgets that these labels describe. XIML supports design, operation, organization, and evaluation functions; it is able to relate the abstract and concrete data elements of an interface; and it enables knowledge-based systems to exploit the captured data.
Sistem from based:
Mecano (Puerta)
Trident (Vanderdonckt)
Maria XML
Revangie
MB-IDEs
ITS
Humanoid
Digbe
DIGBE automatically provides a well-designed, user specialized interface for each user. It also adapts
dynamically as it supports the collaboration between the user and the system, by:
automatically designing an appropriate application shell and required task interactions,
dynamically specializing this interface based on the current user and domain situation, and
interactively presenting the user interface for the interactions that are required on the user's selected device (CRT or handheld).
Each active DIGBE system automatically designs and presents itself, dynamically responds to changes in
application objects, and tunes itself to the role and security properties of the user, the selected device, and the tasks that are active. The basis of these capabilities is the knowledge that DIGBE possesses about dynamic interaction generation
XSFORM
Although the aforementioned efforts have provided useful tools to ease the task of building form-based XML information processing applications, fair
amount of repetitive development efforts on formbased GUI is still not avoidable when the user needs
to deal with XML documents of different schemas. To address this problem, this research has developed a form-based XML information processing
application, called XsForm, that is driven by the userinput XML schema to automatically generate
appropriate Windows forms and associated functions. This paper discusses the development of XsForm and its application to promote e-business in the
construction industry.
The system should build an appropriate formbased GUI automatically based on the user-input XML schema to facilitate the gathering, editing, and management of XML information associated with the schema. In addition, the system should allow input of a new schema at any time and rebuild its form-based GUI accordingly and automatically.
� The system should provide functions for saving the information into an XML file that is wellformed and valid with respect to the user-input
XML schema as well as for searching and querying XML information in the XML files managed by the system.
According to the requirements discussed above, the architecture of XsForm is designed as shown in Fig. 1. The arrows in Fig. 1 show the data flow between the user, the XsForm functional components (in the business logic tier and UI tier), and the XsForm functional components (in the data tier). XsForm takes an XML schema as input and uses the
Schema2UIML component to parse and transform the XML schema into the corresponding UIML file. UIML (User Interface Markup language) [9], an XML language for defining user interfaces, is employed in this work to describe and record detailed information about the required GUI. The recorded information is then used by the UIML2GUI component to create Windows forms and associated functions. The above process from the input of XML schema to the creation of corresponding Windows forms is performed automatically by XsForm.
XsForm can also take a valid XML file as input. In this case, the system finds and loads the
produced are not only well-formed but also valid with respect to the user-input schema.
UIML 3.0 Language Specification 1. Define an XML schema to describe the structures, contents, and semantics of the set of forms. Although this step requires some fair amount of efforts, the resulted XML schema is the key document for sharing and exchange of the information in the set of forms with collaborative parties in the e-business process. 2. Execute XsForm and read the XML schema into XsForm.
3. XsForm automatically and quickly generates appropriate Windows forms for the user to digitalize and edit data in the forms. It also allows the user to save the data in the XML files that is well-formed and valid with respect to the given XML schema.
4. The XML files and the XML schema can then be used in the e-business process for information sharing and exchange.
Liquid-Interface
INTRODUCTION
Dynamic composition is a new way for creating software applications. Rather than manual coding the new application, the application is generated automatically by reusing existing software services according to the user’s requirements [3],
[7]. The method has several advantages: it answers an instantaneous request of the user, and the application is flexible:
the application can change instantly, reacting to changes in the underlying services (e.g. failures, price change, quality of service etc). While dynamic composition promises an exciting vision for software development, it raises several questions regarding the way users interact with the generated application. Specifically, it raises a challenge for usability, which is defined as the effectiveness, efficiency and satisfaction in which users perform tasks using a given system [1].
In traditional software development processes, the userinterface is derived from the requirements and desired functionality of the application model. It can be carefully designed and tested in order to insure its usability. In contrast, in dynamically composed applications, the functionality is not set during the design of the system. Therefore, it the userinterface cannot be designed, let alone tested for usability.
The conclusion is that the user-interface should be generated dynamically as well, reflecting the temporary functionality of the application.
order to generate user-interfaces [5], [4], [6]. While modelbased user-interfaces provide the foundations for automatic
generation of user-interfaces, they do not deal with usability optimization as they presume the models are already usable. However, this approach will not suffice for dynamic compositions, as these compositions are not optimized for usability
Method
The input to the generation process is a model of
dynamically-composed application, written in OWL-S [2],
which is a widespread language used to define dynamic compositions using rich semantic models. The parts of the OWLS
model which are relevant to this research are the process model, which defines the execution order of the processes, and the process specification, which defines the input and output parameters of processes using ontological concepts. In order to exemplify our approach we use a simple composition, depicted in Figure (a), describing a book buying application. The application is composed of three sub-processes, represented by the ellipses and ordered as a sequence. The square objects represent input and output parameters of the processes. The user-interface generation process creates a Web-form for each sub-process, generating the form’s fields from the input and output parameters. Figure (b) contains a screenshot of such a form, generated for the process model in Figure (a).
GuiGen
GuiGen is a comprehensive set of tools for creating customized graphical user interfaces (GUIs). It draws from the concept of computing portals, which are here seen as interfaces to application-specific computing services for user communities. While GuiGen was originally designed for the use in computational grids, it can be used in client/server environments as well.
GuiGen helps application experts to design customized GUIs for different application domains. In GuiGen, the user interface is split into two parts: a platform independent GUI that can be easily tailored to the specific needs of a user community, and the machine specific back-ends, one for each potential target system. The GUIs (called Forms) and the back-ends (called JobTemplates) can be maintained in repositories for later re-use.
Mesca
Mesca [29] merupakan implementasi dari disain menu berbasis kasus (case-based). Pustaka kasus terdiri dari berbagai menu dari berbagai aplikasi yang ada pada berbagai sistem operasi dan berbagai bidang. Sistem mengambil jenis aplikasi yang akan dikembangkan dari layar dialog, sistem operasinya apa dan bidang apa. Kemudian algoritma pemadanan (matching algorithm) melakukan pemadanan secara cerdas. Berikutnya pengguna diberi kesempatan untuk memilih menu terbaik dari kasus yang diperoleh. Hasilnya, berupa solusi, kemudian digunakan langsung dalam aplikasi yang dibangun.
These are features of a case :
Function of the menu : e.g. File, Edit, Format, Help etc.
Operating system on which the software is supposed to run : e.g. Windows95, DOS, Macintosh,
UNIX etc.
If the application is tailored to a specific field : e.g. Statistics, Mathematics, Chemistry etc. The degree to which the application is graphics oriented, on scale of 1 to 3.
The level of computer literacy expected from the user of the software developed, on scale of 1 to 3.
CASE BASED REASONING APPROACH TO CREATING USER IN... http://www.sigchi.org/chi96/proceedings/intpost/Joshi/js_txt.html 2
CbaUI (Case Based Adaptive User Interface) Widget
Adaptation is referred to the notion of changing something to meet some specific requirements or purposes [1]. Adaptive systems are described as tools which develop new information about how to do the task better by analysing past experience and relating it to performance criteria set by humans [2]. It is also stated that an adaptive system adapts its behaviour to individual users based on information about them which is either implicitly collected during the user-system interaction or users are explicitly asked for it, and the adaptive system performs the adaptation using some form of learning, inference or decision making [3].
Prinsip
Metode/pendekatannya
Contoh output
5 Referensi
1. Krueger, C.W.; Software Reuse; 1992.
4. Gomes, P.; A Case-Based Approach to Software Design; disertasi PhD; 2003. 5. Almeida, E.S. et.al., A Survey on Software Reuse Processes, 2005
6. Neighbors, J.M.; Software Construction Using Components, 1980 7. Kaur, A., Goyal, R.; Software Reuse Library; 2012.
8. Prieto-Díaz, R.; Status Report: Software Reusability, 1993
9. Lucredio, D. et al; The Draco Approach Revisited: Model-Driven Software Reuse; 2006 10. Al Hijaj, A.A., et al; Using of Software Reuse Approaches to Develop UGELIB Web
Application, 2009
11. Nath, R.; Kumar, H.; A Review of Approaches to Software Reuse, 2008.
12. Shaw, M.; Architectural Issues in Software Reuse: It’s Not Just the Functionality, It’s the Packaging; 1995.
13. Dusink, E.M.; Reuse is not done in a vacuum; 1992.
14. Smolarova, M., Navrat, P.; Software Resuse: Principles, Patterns, Prospects; 1998 15. Main, J., et al; A Tutorial on Case-Based Reasoning, 2001.
16. Fouqut, G. Matwin, S.; Compositional Software Reuse with Case-Based Reasoning, 1993.
17. Fouqut, G. Matwin, S.; CAESAR: a System for CAse-BasEd SoftwAre Reuse; 1992 18. Smyth, B.; Cunningham, P.; Deja Vu: A Hierarchical Case-Based Reasoning System for
Software Design; 1992.
19. Gonzalez, P.A.; Fernandez, C.; A Knowledge-Based Approach to Support Software Reuse in Object-oriented Libraries, 1997
20. Gonzalez, P.A.; Applying Knowledge modelling and Case-Based Reasoning to Software Reuse; 2000.
21. Tautz, C., Althoff, K.; Using Case-Based Reasoning for Reusing Software Knowledge; 1997.
22. Spanoudakis, G., Constantopoulos, P.; Analogical Reuse of Requirements Specifications: A Computational Model; 1996.
23.
24. Hsieh S-H.; Lin, H-T.; XSFORM: A SCHEMA-DRIVEN FORM-BASED XML INFORMATION PROCESSOR; 2004
25. Toch, E., Reinhartz-Berger, I, Dori, D; Liquid-Interface: Automatically Generating and Optimizing User-Interfaces for Dynamic Compositions, 2008
26. Penner, R, Steinmetz, E.S; DIGBE: Adaptive User Interface Automation; 1999.
27. Reinefelda, A., Stuben, H., Florian Schintke, F., Din, G.; GuiGen: A Toolset for Creating Customized Interfaces for Grid User Communities, 2002
29. Joshi, S.R., McMillan, W.W.; Case Based Reasoning Approach to Creating User Interface Components, 1996.
30. Marir, F.; Case Based Reasoning for an Adaptive Web User Interface; 2012 31. m
