Nama : Widya Nengsi Purnomo

Nim : 201510370311027

Review Jurnal Design annotations to improve API discoverability

1. Abstract
Studi pengguna telah mengungkapkan bahwa programmer menghadapi beberapa kendala
ketika belajar aplikasi antarmuka pemrograman (API). Sebagian besar kesulitan tersebut
berkaitan dengan penemuan elemen API dan hubungan di antara mereka. Untuk mengatasi
masalah yang dapat ditemukan, kami menunjukkan cara melengkapi API dengan anotasi
desain, yang mendokumentasikan keputusan desain dalam bentuk yang dapat diproses program
untuk tipe, metode, dan parameter. Informasi yang diberikan oleh anotasi dikonsumsi oleh
lingkungan pengembangan terintegrasi (IDE) untuk membantu pengguna API dengan proposal
penyelesaian kode yang berguna mengenai pembuatan dan manipulasi objek, yang
memfasilitasi eksplorasi dan pembelajaran API. Sebagai bukti konsep, kami mengembangkan
Dacite, alat yang terdiri dari serangkaian anotasi Java dan plugin yang menyertainya untuk
Eclipse IDE. Sebuah studi pengguna mengungkapkan bahwa Dacite dapat digunakan dan
efektif, dan proposal Dacite memungkinkan para programmer untuk lebih berhasil dalam
menyelesaikan tugas-tugas pemrograman yang melibatkan API yang tidak dikenal.

2. Pendahuluan
Menulis program dan menggunakan antarmuka pemrograman aplikasi (API) adalah
kegiatan yang tidak terpisahkan dalam rekayasa perangkat lunak modern; Tidak layak untuk
menulis program tanpa menggunakan API pihak ketiga, misalnya menangani tipe data, GUI,
atau jaringan (Myers dan Stylos, 2016). API dikembangkan oleh desainer API, yang mewakili
sebagian kecil dari programmer dan biasanya memiliki keterampilan teknis yang kuat,
sedangkan program pengguna API terhadap API dan mewakili hampir semua orang yang
menulis kode, banyak di antaranya memiliki latar belakang yang berbeda dari komputer. sains
(Scaffidi et al., 2005). Karena kerumitan perangkat lunak meningkat, baik karena kompleksitas
domain intrinsik dan persyaratan non-fungsional (misalnya, adaptabilitas dan usabilitas), API
dapat menjadi lebih kompleks, dan akibatnya, lebih sulit digunakan. Meskipun solusi yang
ditawarkan oleh pola desain diperlukan, mereka sering memperkenalkan kompleksitas desain.
Meskipun pola desain meresap dalam rekayasa perangkat lunak, itu mungkin tidak terlihat oleh
pengguna API ketika digunakan.
Penelitian sebelumnya menunjukkan jika programmer menyadari pola tertentu, mereka tidak
selalu mengharapkan ketika mencoba untuk belajar API (Ellis et al., 2007). Pola desain yang
kelas partisipannya diekspos dalam API berpotensi memperkenalkan kesulitan tambahan untuk
pengguna API. Misalnya, mengingat bahwa dalam situasi tertentu pengguna tidak akan dapat
membuat objek API melalui cara yang paling "alami" (yaitu, menggunakan konstruktor),
mereka harus menemukan metode yang berpotensi ditempatkan di kelas yang berbeda yang
akan memungkinkan mereka untuk membuat objek yang diinginkan. Sebagai contoh lain,
fungsionalitas penting yang terkait dengan objek tertentu mungkin tersedia dalam metode yang
terdapat dalam kelas pembantu, yang juga mungkin tidak mudah ditemukan. Studi pengguna
mengungkapkan bahwa hambatan penemuan ini memiliki dampak yang besar terhadap
pembelajaran API (Ellis et al., 2007; Stylos dan Myers, 2008; Duala-Ekoko dan Robillard,
2012).
coverability dengan cara melengkapi API dengan anotasi desain, yang secara eksplisit dan
formal mengandung informasi mengenai keputusan desain. Tujuan utama dan keuntungan dari
memiliki anotasi ini adalah untuk mengaktifkan lingkungan pengembangan terpadu (IDE)
untuk membantu pengguna API dengan proposal penyelesaian kode yang berguna berdasarkan
informasi yang terkandung dalam anotasi. Keuntungan lebih lanjut adalah bahwa eksperimen
empiris telah menunjukkan bahwa mendokumentasikan pola desain dalam pelaksanaannya
bermanfaat untuk pemeliharaan sistem (Prechelt et al., 2002). Oleh karena itu, sebagai efek
samping, anotasi desain kami juga memainkan peran artefak dokumentasi dalam kode sumber,
selain dokumentasi konvensional. Meskipun telah ditunjukkan bahwa kadang-kadang mungkin
untuk secara otomatis mendeteksi pola desain dalam kode sumber (Tsantalis et al., 2006),
pendekatan semacam ini belum ditargetkan pada bantuan penggunaan API tetapi pada
pemahaman program secara umum. Merancang kumpulan kecil anotasi Java dan prosesor
anotasi yang dapat digunakan oleh desainer API untuk menerapkan pendekatan dalam API
mereka. Anotasi ini cukup sederhana untuk desainer API untuk memasukkan, mengingat
bahwa dalam banyak kasus mereka hanya memformalkan (yaitu dalam bentuk program-
formable) informasi yang biasanya biasanya hadir dalam dokumentasi informal (yaitu teks
bentuk bebas). Anotasi memiliki keuntungan divalidasi oleh prosesor terhadap aturan-aturan
well-formedness. Kami mengembangkan sebuah plugin untuk lingkungan pengembangan
terintegrasi Eclipse (IDE) yang memungkinkan pengguna API untuk mendapatkan pengaruh
dari anotasi desain, dalam bentuk yang diintegrasikan dengan mekanisme penyelesaian kode
yang ada. Kami membahas desain API yang dapat menyebabkan berbagai masalah dapat
ditemukan, melibatkan pola umum dan idiom (Gamma et al., 1995; Bloch, 2008), yaitu pabrik
statis, metode pabrik, pembangun objek, metode pembantu, dekorator, dan objek komposit .
Dacite menyediakan mekanisme terpadu untuk mengatasi diskabilitas API berdasarkan
memperkaya API dengan penjelasan kode. Dengan cara ini, pengembang API mendapatkan
kendali atas proposal penyelesaian kode yang berkaitan dengan API yang dapat ditemukan
yang direkomendasikan oleh IDE, karena solusi berdasarkan deteksi otomatis dan
penambangan aspek desain API selalu tunduk pada masalah presisi / recall sampai batas
tertentu.
Gbr. 1 menyajikan dua skenario penggunaan pendekatan kami, diilustrasikan dengan Java
Collections API. Kelas java.util.Collections berisi beberapa metode pembantu statis untuk
memanipulasi koleksi, seperti untuk menyortir dan membuat tampilan koleksi yang tidak dapat
diubah. Bagian atas gambar berisi cuplikan dua metode tersebut dengan anotasi desain. Dalam
kasus pertama, metode emptyList () dianotasi dengan @StaticFactory, yang menunjukkan
bahwa ini terdiri dari pabrik statis untuk membuat objek Daftar (tipe kembalian). Dalam kasus
kedua, metode semacam memiliki parameter yang dianotasikan dengan @Helper,
menunjukkan bahwa semacam itu adalah metode pembantu yang dapat digunakan pada objek
Daftar (tipe parameter).
Gambar ini juga menyajikan dua tangkapan layar menu penyelesaian kode Eclipse,
ditingkatkan dengan proposal yang secara otomatis berasal dari anotasi desain. Anotasi desain
dapat diterapkan ke API yang ada tanpa melanggar kode klien. Namun, mungkin juga
diinginkan untuk membuat anotasi API yang tidak dimiliki (mis., Untuk komponen sumber
terbuka), dan oleh karena itu, kami juga menyediakan cara untuk membuat anotasi API secara
eksternal oleh pihak ketiga. Dalam konteks pengembangan perangkat lunak perusahaan
berskala besar, komponen digunakan kembali melalui API di sejumlah komponen lain yang
dikembangkan oleh tim yang berbeda, dan di sini masalah keterkaitan API juga relevan. Dalam
kasus ini, mengingat bahwa semua komponen mengendalikan organisasi yang sama, akan
relatif mudah untuk menegakkan bahwa kode API harus dianotasi, seperti dengan aturan dan
konvensi pengkodean lainnya. Hasil penelitian menunjukkan bahwa programmer
menggunakan Dacite mencapai dua kali lebih berhasil dalam menyelesaikan tugas yang
diberikan. Memberikan bukti bahwa mekanisme penyelesaian kode Dacite dapat digunakan
dan secara efektif membantu pemrogram untuk menemukan informasi yang diperlukan tentang
API. Kontribusi utama dari penelitian ini adalah:
(1) pendekatan terpadu berdasarkan anotasi desain untuk mengatasi pola desain API yang
diidentifikasi sebelumnya dan lainnya yang dapat menghambat penemuan API,
(2) mengidentifikasi pola desain tambahan (seperti dekorator dan pola komposit) yang dapat
memperoleh manfaat dari jenis bantuan ini,
(3) peningkatan ke IDE yang dapat memanfaatkan anotasi desain untuk membantu pengguna
API, dan
(4) keyakinan empiris bahwa peningkatan IDE yang tersedia dapat digunakan dan
memungkinkan pemrogram untuk lebih berhasil dalam memecahkan tugas pemrograman yang
melibatkan API yang tidak dikenal.

3. Implementation
Di Java, anotasi diperlakukan seperti jenis (secara sintaksis, mereka didahului oleh "@"),
dan karenanya, mereka diperiksa oleh kompiler. Lebih lanjut, anotasi mungkin memiliki
parameter yang argumennya memiliki nilai. Ketika mendefinisikan jenis anotasi, hanya
mungkin untuk menentukan jenis anggota yang dapat diterapkan (misalnya, metode,
konstruktor, parameter, dll). Namun, anotasi desain Dacite memerlukan lebih banyak validasi
rumit saat menerapkannya yang kami periksa. Misalnya, anotasi @StaticFactory hanya dapat
diterapkan ke metode statis publik yang mengembalikan tipe referensi. Validasi ini dilakukan
oleh prosesor anotasi, memancarkan pesan kesalahan kompilator ketika pelanggaran terdeteksi.
Anotasi mungkin memiliki kebijakan retensi yang berbeda, yang menyiratkan bahwa mereka
dikodekan dalam file .class biner atau tidak. Mengingat bahwa informasi yang terkandung
dalam anotasi disimpan dalam deskriptor elemen desain (ingat Gambar. 2),

Penjelasan tidak diperlukan untuk hadir pada runtime 4 (semua informasi yang relevan dalam
dikumpulkan dalam indeks). Kami mengembangkan prosesor anotasi di Jawa melalui
infrastruktur standar yang disediakan untuk memperluas kompilator sehubungan dengan
penanganan anotasi. Mengembangkan sebuah plugin prototipe untuk Eclipse IDE
menggunakan mekanisme penyelesaian kode kelengkapannya, memungkinkan beberapa API
disediakan dengan anotasi desain untuk digunakan secara bersamaan. Proposal penyelesaian
kode IDE didasarkan pada indeks dalam memori. Indeks diisi dengan informasi yang
disediakan dalam deskripsi elemen desain, yaitu file XML yang menyandikan anotasi pada
anggota struktural API.

Gambar. 3 menyajikan contoh kutipan deskriptor untuk membubuhi keterangan pabrik statis.
Sejauh ini, kami belum mengembangkan editor khusus untuk pihak ketiga eksternal yang
digunakan untuk membuat anotasi API secara eksternal, tetapi ini akan mudah dicapai di masa
depan. Untuk penjelasan API internal, deskriptor yang dihasilkan oleh prosesor anotasi
dikemas dalam file JAR perpustakaan. Untuk mengisi indeks, IDE mencari pendeskripsi di
semua file JAR yang tersedia di jalur build. Sehubungan dengan anotasi eksternal, deskriptor
disediakan secara terpisah sebagai plugin Dacite (tidak ada kode yang harus disediakan), yang
dimuat saat runtime oleh IDE dan juga digunakan untuk mengisi indeks.

4. Kesimpulan
Pendekatan yang diambil dalam pekerjaan ini meningkatkan kemampuan penemuan API
dengan teknik baru berdasarkan pada penambahan kode implementasi API dengan anotasi
desain. Keuntungan utama dari apa yang kami berikan atas pendekatan yang ada adalah untuk
memungkinkan pengguna API untuk dibantu dalam IDE sehubungan dengan penemuan
elemen API, tanpa bergantung pada contoh kode, corpora atau bentuk eksplorasi dokumentasi
alternatif. Dalam pendekatan kami, desainer API mengendalikan pembuatan eksplisit
hubungan antara elemen API. Penerapan Dacite berdiri sebagai bukti konsep untuk kelayakan
pendekatan kami, dan studi pengguna kami memberikan bukti bahwa itu dapat digunakan dan
efektif dari sudut pandang pengguna API.