Pendekatan Berbasis Metadata untuk Menerapkan Konvensi Atas Konfigurasi yang Dipisahkan dari Logika Kerangka Kerja

ABSTRAK
Kerangka kerja sangat penting untuk pengembangan perangkat lunak, menyediakan desain kode dan memfasilitasi penggunaan kembali bagi penggunanya. Kerangka kerja dan API Java yang terkenal bergantung pada konfigurasi metadata melalui anotasi kode, menggunakan API Refleksi untuk mengonsumsi dan memprosesnya. Elemen kode yang berbagi anotasi yang sama sering kali menunjukkan kesamaan, menciptakan peluang untuk menggunakan konvensi sebagai sumber metadata. Makalah ini mengusulkan model untuk mendefinisikan Konvensi atas Konfigurasi (CoC) untuk penggunaan anotasi, dipisahkan dari logika pembacaan metadata. Dengan model ini, jika ada konvensi, kerangka kerja akan secara otomatis menganggap elemen tersebut diberi anotasi. Kami menerapkan model ini di Esfinge Metadata API dan mengevaluasinya dalam sebuah eksperimen di mana para peserta menerapkan pola CoC menggunakan dua pendekatan: pendekatan yang kami usulkan dan Java Reflection API. Hasilnya, 75% peserta menerapkan pendekatan kami lebih cepat daripada hanya dengan Reflection API, dan kami mengamati tingkat kegagalan yang lebih tinggi dengan Reflection API daripada dengan Esfinge API. Selain itu, kode yang dihasilkan dengan pendekatan kami juga menghasilkan lebih sedikit baris kode. Berdasarkan hasil ini, kami mengonfirmasi bahwa pendekatan yang diusulkan memenuhi tujuannya untuk mendukung definisi konvensi yang dipisahkan dari logika kerangka kerja, sehingga meningkatkan keterbacaan dan pemeliharaan kode.

1 Pendahuluan
Kerangka kerja adalah perangkat lunak tidak lengkap yang dapat dikhususkan oleh pengembang untuk menambahkan perilaku khusus aplikasi. Dengan menawarkan serangkaian abstraksi, pengembang dapat menyusun dan memperluas kerangka kerja untuk membuat aplikasi yang lengkap. Kerangka kerja berbasis metadata [ 1 ] memanfaatkan konfigurasi metadata untuk menentukan cara mengadaptasi perilaku untuk setiap kelas. Dalam bahasa Java, pengembang terutama menggunakan anotasi kode untuk konfigurasi metadata. Kerangka kerja yang banyak digunakan seperti Spring, Hibernate, dan JUnit menggabungkan anotasi sebagai inti dari API mereka.

Selama bertahun-tahun setelah penambahan fitur bahasa ini, kami memiliki bukti empiris bahwa penggunaan anotasi tersebar luas dalam proses pengembangan perangkat lunak modern. Beberapa studi empiris membuktikan keberadaan kelas yang kelebihan beban dengan anotasi dan konfigurasi yang sangat berulang [ 2 , 3 ]. Penyalahgunaan lain dari penggunaan anotasi kode adalah bahwa beberapa anotasi dapat memerlukan konfigurasi yang ekstensif [ 4 ]. Namun, mengingat bahwa beberapa kerangka kerja mengadopsi pendekatan API yang dianotasi, ada risiko penggunaan anotasi yang berlebihan, yang dapat membahayakan keterbacaan dan pemeliharaan kode. Kami dapat menemukan laporan dari praktisi tentang masalah itu. Misalnya, praktisi mengeluh bahwa anotasi mencampur konfigurasi dengan kode sumber yang sebenarnya [ 5 ]. Pengembang juga mengklaim bahwa anotasi bertentangan dengan prinsip enkapsulasi [ 6 ] karena perilaku objek tidak ditentukan hanya oleh metodenya. Meskipun kompiler memeriksa parameter anotasi dan jika elemen kode yang dianotasi cocok dengan tipe target anotasi, tidak ada jaminan apakah konteks tempat anotasi digunakan sudah benar [ 7 , 8 ]. Sebaliknya, anotasi kurang bertele-tele dibandingkan file XML [ 5 ] dan membawa konfigurasi mendekati kode sumber. Pendekatan konvensi kode dapat mengurangi konfigurasi metadata.

Konvensi kode adalah panduan untuk penulisan kode sumber. Mengadopsi konvensi kode penting ketika tim pengembangan berkolaborasi dalam sebuah proyek karena dapat meningkatkan keterbacaan dan pemeliharaan kode [ 9 ]. Panduan ini mencakup beberapa aspek dari proses pengembangan, seperti penamaan variabel, pemformatan kode, dan dokumentasi. Selain itu, pengembang dapat menggunakannya sebagai pendekatan untuk definisi metadata [ 10 ] berdasarkan pola yang disebut Konvensi atas Konfigurasi [ 11 ]. Praktik ini dapat secara signifikan mengurangi jumlah anotasi kode dan jenis konfigurasi lainnya [ 4 ], menjadi alternatif untuk masalah yang terkait dengan pengulangan dan penggunaan anotasi yang berlebihan. Namun, kurangnya dukungan untuk praktik desain ini membatasi penggunaannya. Dengan demikian, tidak ada API atau alat pembacaan metadata yang mendukung kerangka kerja pada implementasi Konvensi atas Konfigurasi . Bahkan jika pengembang dapat menggunakan pola desain untuk membaca metadata, seperti Strategi Pembaca Metadata dan Rantai Pembaca Metadata [ 12 , 13 ], mereka masih perlu memeriksa konvensi dan mengidentifikasi metadata yang sesuai secara terprogram. Kami membahas pola desain ini di Bagian 2.3 . Selain itu, praktisi melaporkan bahwa konvensi sering disembunyikan dalam kode sumber, yang menyebabkan hasil yang tidak diinginkan atau tidak diharapkan [ 14 , 15 ]. Terakhir, pengembang harus menulis kode tambahan untuk menimpa beberapa konvensi yang diberlakukan oleh kerangka kerja [ 16 ].

Dalam karya ini, kami mengusulkan model untuk mendefinisikan solusi guna mendukung penggunaan konvensi atas konfigurasi untuk kerangka kerja berbasis metadata guna membantu pengembang dalam mengimplementasikan kerangka kerja berbasis metadata. Pendekatan kami menggunakan anotasi konvensi tambahan untuk mengonfigurasi anotasi kerangka kerja. Anotasi konvensi mendefinisikan konvensi yang menggantikan anotasi target saat elemen kode cocok dengan konvensi. Dengan demikian, API pembacaan metadata akan mengembalikan nilai yang sama secara transparan saat anotasi kerangka kerja ada atau elemennya cocok dengan konvensi kode. Dengan cara ini, logika pembacaan metadata kerangka kerja hanya dapat mempertimbangkan anotasi kerangka kerja, yang memungkinkan API pembacaan metadata menangani konvensi secara transparan. Selain itu, konvensi akan dideklarasikan dalam definisi anotasi target dan dipisahkan dari logika kerangka kerja.

Bahasa Indonesia: Kami membuat implementasi referensi sebagai fitur dari kerangka kerja Esfinge Metadata [ 17 – 19 ] untuk mengevaluasi kelayakan model kami. Esfinge Metadata API adalah meta-kerangka kerja untuk membaca dan memvalidasi anotasi. Mekanisme yang diimplementasikan dalam Esfinge Metadata API dapat diperluas. Kami memperluas pembacaan metadata, termasuk pendekatan kami. Dengan menggunakan versi baru Esfinge Metadata, pertama-tama kami melakukan studi kasus dengan melakukan refaktor Esfinge Comparison [ 1 ], sebuah kerangka kerja yang membandingkan dua instans kelas. Kerangka kerja ini menggunakan Esfinge Metadata API sebagai API pembacaan metadatanya [ 18 ]. Dalam studi ini, kami melakukan refaktor kerangka kerja Esfinge Comparison, dengan menambahkan anotasi konvensi ke anotasi target.

Kami mengevaluasi solusi kami dengan menggunakan pengujian unit untuk setiap konvensi yang diterapkan. Hasilnya, konvensi dapat diterapkan hanya dengan menambahkan definisinya dalam anotasi target, dipisahkan dari logika kerangka kerja Esfinge Comparison. Sebagai validasi kedua, untuk melengkapi studi kasus, kami juga melakukan eksperimen dengan 28 mahasiswa sarjana menggunakan kerangka kerja subjek untuk memetakan parameter baris perintah ke atribut kelas. Setiap peserta menerapkan dua konvensi menggunakan pendekatan yang kami usulkan dan dua konvensi hanya menggunakan Java Reflection API. Hasilnya, pendekatan yang kami usulkan memisahkan kode yang ditambahkan dari logika kerangka kerja subjek, dan para peserta merasa lebih mudah untuk membaca dan memeliharanya. Berdasarkan hasil ini, kami menyimpulkan bahwa model yang diusulkan memenuhi tujuannya sebagai dukungan yang sesuai untuk menerapkan pola Convention over Configuration. Dengan pendekatan baru ini, kami mencatat kecepatan pengembangan yang jauh lebih cepat dibandingkan dengan penggunaan Reflection API. Para peserta mengidentifikasi kurva pembelajaran sebagai kesulitan utama dari pendekatan ini. Kompleksitas kode juga dianggap jauh lebih rendah.

Sisa dari makalah ini disusun sebagai berikut: Bagian 2 menyajikan konsep untuk metadata dalam pemrograman berorientasi objek. Bagian 3 menyajikan pendekatan baru kami untuk konvensi atas konfigurasi. Implementasi model dirinci dalam Bagian 4. Dalam Bagian 5 , kami menyajikan studi kasus untuk mengimplementasikan konvensi untuk anotasi Perbandingan Esfinge. Kami menyajikan studi yang dirancang untuk mengevaluasi pendekatan kami dalam Bagian 6. Bagian 7 menyajikan hasil yang diperoleh, dan dalam Bagian 8 , kami membahas hasil dan menyajikan ancaman terhadap validitas. Akhirnya, kami menyimpulkan makalah ini dalam Bagian 9 .

2 Latar Belakang
Kami mendefinisikan terminologi yang digunakan dalam makalah ini untuk memandu pembaca dengan lebih baik. Saat merujuk ke fitur anotasi Java, kami menggunakan istilah anotasi kode atau hanya anotasi . Kami menggunakan anotasi konvensi untuk merujuk ke anotasi yang mendefinisikan konvensi. Akhirnya, kami menggunakan anotasi target atau anotasi kerangka kerja untuk merujuk ke yang menerima konvensi. Ketika kami merujuk ke kerangka kerja secara umum, kami mengatakan kerangka kerja . Mengenai kerangka kerja yang dikembangkan atau digunakan dalam penelitian ini, kerangka kerja perbandingan mengacu pada kerangka kerja yang digunakan dalam studi kasus, dan kerangka kerja subjek mengacu pada kerangka kerja yang digunakan untuk mengevaluasi pendekatan kami. Akhirnya, ketika kami mengatakan kerangka kerja referensi atau kerangka kerja implementasi , kami mengacu ke Esfinge Metadata API, tempat kami mengimplementasikan model kami.

Subbagian berikut diawali dengan pembahasan konfigurasi metadata dan bagaimana beberapa bahasa pemrograman mengimplementasikan fitur ini. Kami juga memperkenalkan konsep Konvensi Kode dan bagaimana alat atau kerangka kerja menggunakan praktik ini. Kemudian, kami membahas kerangka kerja berbasis metadata, dengan menyajikan pola desain yang digunakan oleh kerangka kerja ini untuk mengurangi penggunaan anotasi. Terakhir, kami menyajikan dampak penggunaan anotasi kode dalam pengembangan kode.

2.1 Konfigurasi Metadata
Istilah “metadata” digunakan dalam berbagai konteks dalam ilmu komputer. Dalam semuanya, itu berarti data yang mengacu pada data itu sendiri. Misalnya, metadata mengacu pada struktur tabel dalam konteks basis data. Dalam konteks berorientasi objek, data adalah contoh objek, dan metadata adalah definisi kelas. Bidang kelas, pada gilirannya, memiliki tipe, pengubah akses, dan nama sebagai metadatanya. Ketika pengembang menggunakan refleksi, metadata suatu program dapat diakses dan dimanipulasi, memungkinkan kode untuk bekerja dengan kelas yang sebelumnya tidak dikenal [ 1 ].

Salah satu pendekatan untuk mendefinisikan metadata kustom adalah dengan menggunakan file eksternal, seperti file XML atau database [ 10 ]. Namun, dalam pendekatan ini, metadata dan elemen kode berjarak jauh karena file eksternal perlu merujuk ke elemen tersebut. Kelemahan lain dari pendekatan ini adalah verbositasnya, karena memerlukan penyediaan jalur lengkap agar kerangka kerja dapat menggunakan metadata dengan benar. Alternatif lain yang digunakan beberapa kerangka kerja untuk definisi metadata adalah konvensi kode, yang akan kami bahas lebih lanjut di Bagian 2.2 .

Beberapa bahasa pemrograman menyediakan fitur yang memungkinkan metadata kustom didefinisikan dan disertakan langsung pada elemen pemrograman, seperti atribut dalam C# [ 20 ] dan anotasi kode dalam Java [ 21 ]. Pendekatan ini memungkinkan definisi metadata lebih dekat ke elemen pemrograman, menjadi kurang bertele-tele daripada menggunakan file XML eksternal. Selain itu, tidak seperti pendekatan lain, pengembang secara eksplisit mendefinisikan metadata dalam kode sumber. Beberapa penulis menyebut penggunaan anotasi kode sebagai pemrograman berorientasi atribut karena menandai elemen perangkat lunak [ 22 , 23 ]. Anotasi dapat digunakan untuk pembuatan kode sumber [ 24 ], verifikasi waktu kompilasi [ 25 , 26 ], transformasi kelas [ 27 ], dan adaptasi kerangka kerja [ 1 ].

Beberapa API dasar menggunakan anotasi secara ekstensif untuk mengonfigurasi metadata. Dukungan anotasi asli ini mendorong banyak kerangka kerja Java dan pengembang API untuk mengadopsi pendekatan berbasis metadata dalam solusi mereka. Mereka juga menanggapi kecenderungan untuk menyimpan file metadata di dalam kode sumber alih-alih menggunakan file terpisah [ 28 ]. Bahasa Java menyediakan Java Reflection API, yang memungkinkan pengembang untuk mengambil anotasi kode saat runtime.

2.2 Konvensi Kode
Konvensi kode adalah aturan untuk memandu pengembang ke gaya, praktik, atau metode pemrograman. Aturan yang ditentukan oleh konvensi kode mencakup penamaan elemen kode yang baik yang menghubungkan pengenal ke domain dan peran arsitektur [ 29 ] dan pemformatan kode sesuai dengan aliran kontrol [ 30 ]. Tujuan dari rekomendasi ini adalah untuk mengembangkan kode yang aman dan lebih mudah dirawat [ 31 ], lebih sedikit rawan kesalahan [ 32 ], dan lebih mudah dibaca [ 33 ]. Tidak adanya kesesuaian dengan konvensi adalah masalah berulang yang ditunjukkan oleh peninjau kode, menurut sebuah studi baru-baru ini [ 34 ].

Pengembang dapat menggunakan konvensi kode sebagai alternatif untuk mendefinisikan metadata kode yang akan digunakan oleh kerangka kerja dan API [ 10 ]. Saat menggunakan metadata, kerangka kerja menggunakan informasi tentang elemen, seperti pengenal, untuk menyimpulkan informasi tambahan tentangnya. Misalnya, spesifikasi JavaBeans [ 35 ] mendefinisikan bahwa get dan set harus digunakan sebagai awalan untuk mengidentifikasi metode yang masing-masing mengambil dan mengatur informasi ke dalam kelas. Kerangka kerja dan API berbasis refleksi biasanya bergantung pada kelas aplikasi yang mengikuti beberapa konvensi khusus untuk menjalankan fungsinya.

Pola yang disebut Convention Over Configuration [ 11 , 36 ] menyatakan bahwa framework dan API harus menerapkan konvensi penamaan standar untuk memetakan kelas ke sumber daya atau peristiwa. Ruby on Rails adalah framework yang dikenal mengadopsi praktik ini sebagai inti solusinya [ 37 ], dan framework lain mengikutinya. Praktik pelengkap, Configuration by Exception, mempertimbangkan untuk mendefinisikan metadata pada elemen yang menyimpang dari aturan konvensi. Misalnya, JPA API mempertimbangkan sebagai konvensi untuk pemetaan objek-relasional bahwa bidang kelas memiliki nama yang sama dengan kolomnya masing-masing di tabel database—yang mengharuskannya untuk dikonfigurasi secara eksplisit dengan anotasi hanya jika asumsi ini tidak berlaku [ 38 ].

Terlepas dari peningkatan produktivitas dalam beberapa konteks, pendekatan ini memiliki ekspresi yang terbatas. Dengan demikian, pengembang tidak dapat menggunakannya untuk menentukan metadata yang kompleks. Misalnya, konvensi kode akan cocok untuk menentukan metode pengujian dalam kerangka kerja pengujian (seperti JUnit). Namun, itu tidak akan menentukan rentang nilai numerik yang valid dalam API validasi instans (seperti Validasi Bean). Kelemahan dari pendekatan ini adalah bahwa metadata tidak eksplisit dalam kode sumber, yang dapat menyebabkan kesalahan [ 39 ]. Misalnya, dengan mengubah nama kelas, pengembang mungkin secara tidak sengaja mengubah metadata yang mendorong perilaku aplikasi.

Bahasa Indonesia: Sepengetahuan kami, tidak ada API atau pustaka yang menawarkan fitur apa pun untuk mendukung pembacaan metadata berdasarkan konvensi kode. Saat ini, kerangka kerja yang mendukung konvensi kode harus mengimplementasikannya sebagai bagian dari algoritme pembacaan metadata mereka. Algoritme pembacaan metadata harus memverifikasi apakah elemen kode cocok dengan konvensi kode, lalu menyimpulkan metadata tersebut ada. Ada pola desain yang terdokumentasi untuk pembacaan dan pemrosesan metadata [ 12 , 13 ], yang dibahas lebih lanjut di Bagian 2.3 , yang dapat digunakan sebagai alternatif untuk memisahkan ekstraksi metadata dari konvensi kode selama pembacaan dan pemrosesan anotasi. Namun, bahkan dengan pola-pola ini yang memungkinkan perluasan mekanisme pembacaan metadata baru, kami tidak menemukan register penggunaan praktik ini untuk mengimplementasikan konvensi kode ke dalam kerangka kerja.

Jenis konvensi tertentu yang digunakan dengan anotasi adalah menggunakan anotasi kustom yang didefinisikan oleh aplikasi dan mengonfigurasi anotasi kerangka kerja ke anotasi kustom ini. Pola yang disebut Pemetaan Anotasi [ 40 ] mengimplementasikan pendekatan ini. Anotasi kerangka kerja hadir dalam definisi anotasi aplikasi, dan pencarian mekanisme pembacaan metadata juga ada di dalam anotasi lain yang ada dalam elemen kode target. Esfinge Metadata [ 2 , 19 ], dan API Daileon [ 41 ] memberikan dukungan transparan untuk mengimplementasikan pola ini. Beberapa API Java resmi juga mendukung mekanisme Pemetaan Anotasi, yang mengimplementasikan anotasi domain [ 42 ] yang mewakili metadata domain tingkat tinggi yang dipetakan ke metadata kerangka kerja tingkat rendah.

2.3 Kerangka Kerja Berbasis Metadata
Kerangka kerja terkini menggunakan konfigurasi metadata untuk menawarkan aplikasi tingkat penggunaan ulang yang tinggi dan adaptasi yang lebih baik terhadap kebutuhannya. Kerangka kerja ini dikenal sebagai kerangka kerja berbasis metadata karena memproses logikanya berdasarkan konfigurasi metadata kelas yang instansnya digunakan [ 1 ]. Kerangka kerja Java populer seperti Spring, Hibernate, dan JUnit menggunakan anotasi kode untuk mengonfigurasi metadata.

Pengembang sering merancang API berbasis metadata menggunakan praktik yang tidak ada dalam desain berorientasi objek tradisional. Beberapa praktik bertujuan untuk mengurangi penggunaan anotasi. Karya sebelumnya dari Guerra et al. [ 40 ] menunjukkan beberapa pola yang digunakan oleh API berbasis metadata. Menerapkan dua pola desain dapat mengurangi penggunaan anotasi, Konfigurasi Umum dan Pemetaan Anotasi . Konfigurasi Umum mengusulkan bahwa definisi kelas harus menerima anotasi, bukan metode atau atribut. Saat mengonfigurasi kelas dengan anotasi, kerangka kerja harus mempertimbangkan bahwa semua elemen kelas memiliki konfigurasi default tersebut. Pemetaan Anotasi dapat mengurangi jumlah anotasi pada elemen dengan karakteristik umum. Untuk mencapai ini, pengembang harus membuat anotasi khusus dan memasukkan anotasi kerangka kerja. Komponen dapat mencari konfigurasi tambahan saat runtime, mencari anotasi di dalam anotasi khusus yang dibuat.

Banyak konteks berbeda menggunakan kerangka kerja berbasis Metadata. Karya sebelumnya dari Guerra et al. [ 43 ] mengatalogkan skenario penggunaan kerangka kerja berbasis metadata, masalah yang ingin diselesaikan, dan bagaimana mereka mengimplementasikan solusinya. Penulis mengidentifikasi empat pola. (i) Entity Mapping , di mana metadata memetakan kelas aplikasi ke representasi berbeda. Hibernate [ 44 ] dan JPA [ 38 ] mendukung pemetaan paradigma berorientasi objek ke basis data relasional. (ii) Metadata-based Graphical Component , adalah kasus khusus dari pola Entity Mapping. Pola ini menggunakan metadata untuk menghasilkan komponen grafis berdasarkan kelas aplikasi dan interaksi dengannya [ 45 , 46 ]. (iii) Configured Handler menggunakan metadata untuk menandai metode yang harus menangani peristiwa [ 47 , 48 ]. (iv) Crosscutting Metadata Configuration menggunakan metadata untuk mengonfigurasi variasi pada perilaku crosscutting [ 49 ]. Dependency Injection [ 50 ] menetapkan bahwa anotasi mengonfigurasikan sebuah instance yang harus disuntikkan ke dalam kelas. Bidang kelas yang diberi anotasi menunjukkan bahwa sebuah instance harus ditetapkan ke bidang tersebut. Pabrik dapat digunakan sebagai alternatif penggunaan anotasi. Definisi Aturan [ 51 ] menetapkan bahwa anotasi dapat mengonfigurasikan parameter untuk pemrosesan yang terkait dengan kelas target.

Secara internal, kerangka kerja berbasis metadata menerapkan beberapa pola desain. Pola desain untuk mengembangkan kerangka kerja berbasis metadata diklasifikasikan ke dalam tiga kategori [ 12 ]. (i) Pola Struktural mendokumentasikan praktik terbaik tentang bagaimana kelas kerangka kerja harus terstruktur secara internal. (ii) Pola Pemrosesan Logika bertanggung jawab untuk mendokumentasikan solusi dalam merancang logika kerangka kerja utama, yang memungkinkannya untuk diperluas dan dimodifikasi. Terakhir, (iii) Pola Pembacaan Metadata digunakan untuk mendokumentasikan solusi berulang tentang pembacaan metadata oleh kerangka kerja.

Pola desain Metadata Container dapat digunakan untuk memisahkan pembacaan metadata dan logika aplikasi. Kerangka kerja subjek mengimplementasikan pola ini dan dirinci lebih lanjut di Bagian 6. Strategi Pembaca Metadata menggunakan satu antarmuka untuk mengabstraksikan bagaimana metadata harus dibaca, dan kelas yang berbeda dapat mengimplementasikan pendekatan pembacaan metadata mereka, yang memungkinkannya untuk dibaca dari sumber yang berbeda. Karena konvensi dapat menjadi bagian dari pembacaan metadata, pembacaan konvensi dapat menjadi satu implementasi pola desain Strategi Pembaca Metadata . Metadata juga dapat tersebar di lebih dari satu kelas atau paket. Rantai Pembaca Metadata menyediakan struktur yang diperlukan untuk mengambil metadata dari sumber yang berbeda. Pola desain ini dapat diimplementasikan sebagai Rantai Tanggung Jawab [ 52 ]. Menggunakan Rantai Pembaca Metadata memungkinkan implementasi Strategi Pembaca Metadata untuk menggabungkan metadata ke dalam Repositori Metadata yang sama . Dalam pola desain ini, kelas kontainer menyimpan metadata saat runtime. Repositori mengelola pembacaan metadata dan diakses oleh kerangka kerja untuk mengambil metadata. Esfinge Metadata API [ 19 ] adalah kerangka kerja berbasis metadata yang dikembangkan untuk meningkatkan pembacaan dan pemrosesan metadata pada kerangka kerja berbasis metadata. Esfinge Metadata API menerapkan pola desain yang telah dibahas sebelumnya dan digunakan untuk menerapkan pendekatan yang kami usulkan untuk menambahkan kemampuan konvensi pada pembacaan dan pemrosesan metadata.

2.4 Studi Tentang Dampak Penggunaan Anotasi
Saat ini, beberapa API dan framework populer menggunakan anotasi, sehingga menghasilkan banyak kelas dengan anotasi di proyek yang ada [ 3 , 53 ]. Studi empiris menunjukkan bukti adanya anotasi yang luas, kelas dengan jumlah anotasi yang tinggi [ 53 ], pengulangan anotasi [ 4 ], dan bahwa anotasi tersebut dapat menimbulkan masalah kode [ 3 ].

Percobaan yang membandingkan solusi berbasis metadata dengan solusi lain yang lebih berbasis pada pemrograman berorientasi objek reguler menunjukkan bahwa fungsionalitas yang didefinisikan secara tidak langsung melalui konfigurasi metadata membuatnya sulit untuk di-debug [ 54 , 55 ]. Studi-studi ini juga menunjukkan bahwa penggunaan anotasi dapat mengurangi kopling.

Studi Lima et al. [ 53 ] menyajikan serangkaian metrik untuk penggunaan anotasi dalam kode sumber. Penulis mengamati outlier metrik dengan mengevaluasi data dari 25 proyek Java sumber terbuka, yang mengungkap penyalahgunaan dalam penggunaan fitur anotasi. Misalnya, kelas CoreMessageLogger dari proyek Hibernate Core memiliki 1429 baris kode, yang 789 di antaranya adalah anotasi. Anotasi @LogMessage digunakan 359 kali di kelas ini dalam semua metodenya.

Sebuah studi pada perangkat lunak dari program cuaca luar angkasa Brasil menunjuk redundansi konfigurasi dalam elemen kode dengan karakteristik yang sama [ 4 ]. Hasilnya, penulis menemukan bahwa anotasi yang sama mungkin muncul berkali-kali di banyak kelas yang berbeda. Misalnya, anotasi @Column dari JPA muncul lebih dari 600 kali dalam proyek yang dianalisis. Sebagai hasil utama, penulis menemukan 908 anotasi (21,42% dari total) yang dapat digantikan oleh 17 konvensi khusus aplikasi. Penulis menyarankan bahwa penggunaan konvensi kode berpotensi mengurangi ketidakkonsistenan yang sulit diatasi dan meningkatkan struktur kode.

Yu et al. [ 3 ] mengumpulkan data dari 1094 proyek Java sumber terbuka dan melakukan analisis historis untuk menilai anotasi kode dalam studi empiris skala besar yang menilai penggunaan, evolusi, dan dampak anotasi kode. Studi ini mengungkapkan bahwa banyak perubahan anotasi terjadi selama evolusi proyek, yang menyiratkan bahwa beberapa pengembang menggunakan anotasi secara subjektif dan sewenang-wenang, yang memperkenalkan masalah kode. Penulis menyarankan bahwa pengembang mengasosiasikan penggunaan anotasi dengan kerentanan kesalahan kode. Studi ini menyimpulkan bahwa mereka berpotensi meningkatkan kualitas perangkat lunak. Hasil lain dari studi ini adalah mengidentifikasi hubungan yang kuat antara kepemilikan pengembang dan penggunaan anotasi, yang mengungkapkan bahwa mereka mungkin mengalami kesulitan berkontribusi pada konfigurasi metadata dalam kode yang dibuat oleh orang lain.

Guerra et al. [ 19 ] melakukan percobaan pada pengembangan kerangka kerja. Penulis membandingkan penggunaan API berbasis anotasi dengan satu pendekatan berdasarkan orientasi objek untuk pembacaan metadata menggunakan API Refleksi. Hasilnya menunjukkan perilaku yang lebih konsisten dalam evolusi metrik kopling dan kompleksitas menggunakan pendekatan berbasis anotasi. Namun, tidak ditemukan perbedaan signifikan dalam produktivitas.

Lima et al. [ 56 ] mengembangkan pendekatan visualisasi perangkat lunak untuk meningkatkan pemahaman kode dari sistem berbasis anotasi untuk mengamati distribusi anotasi kode dalam proyek tertentu. Penulis melakukan evaluasi empiris dengan mahasiswa dan pengembang profesional menggunakan aplikasi web Java sebagai sistem target. Dari temuan mereka, penulis mengamati hubungan yang kuat antara keberadaan anotasi kode dan tanggung jawab paket/kelas yang menggunakan anotasi tersebut. Bukti ini mendukung klaim bahwa informasi lain dari kelas, seperti paketnya, dapat digunakan sebagai konvensi untuk menentukan metadata. Temuan ini menunjukkan bahwa anotasi kode juga dapat digunakan untuk menilai desain arsitektur sistem perangkat lunak.

Singkatnya, penggunaan anotasi memiliki dampak positif dan negatif. Anotasi dapat mengurangi kopling [ 54 ], memberikan evolusi kode yang konsisten [ 19 ], dan meningkatkan kualitas kode [ 3 ]. Literatur menyajikan beberapa kelemahan penggunaan anotasi. Deklarasi anotasi dapat ekstensif [ 53 ] dan digunakan untuk mengonfigurasi elemen kode yang sama secara berulang pada kode sumber [ 4 ]. Dampak negatif lainnya adalah anotasi dapat membuat kode sulit di-debug [ 54 ]. Anotasi dapat digunakan secara salah, tidak konsisten, dan berlebihan dalam kode sumber [ 3 ]. Akhirnya, sebuah studi tentang persepsi pengembang tentang keterbacaan kode tidak dapat mencapai konsensus tentang penggunaan anotasi dan keterbacaan kode [ 57 ].

Meskipun ada beberapa strategi yang mengurangi penggunaan anotasi, dan khususnya, beberapa kerangka kerja berbasis metadata yang menerapkan pola Konvensi atas Konfigurasi, masalah utamanya adalah bahwa kerangka kerja atau API harus menerapkan pembacaan konvensi sebagai bagian dari pendekatan pembacaan metadata mereka. Dalam konteks ini, bagian berikut menyajikan model kami untuk memisahkan pembacaan konvensi atas konfigurasi dari kode yang membaca anotasi.

3 Model untuk Menerapkan Solusi Decoupled untuk Konvensi Atas Konfigurasi
Model yang memungkinkan pemisahan definisi konvensi kode dari kode yang membaca anotasi kerangka kerja harus transparan untuk kode yang memeriksa keberadaan sepotong metadata, apakah anotasi target yang sesuai ada atau apakah elemen kode cocok dengan konvensi yang diberikan. Salah satu tujuan dari model yang kami usulkan adalah untuk memungkinkan definisi deklaratif dari konvensi kode sehingga dapat didefinisikan secara terpisah. Salah satu tantangan untuk mencapai tujuan ini adalah bahwa anotasi tidak dapat diwujudkan secara langsung dalam kode Java, dan model tersebut juga menyajikan solusi untuk masalah ini.

Gambar 1 menyajikan urutan untuk mengidentifikasi konvensi secara transparan. Ketika klien aplikasi memanggil metode titik masuk untuk memverifikasi keberadaan metadata, pertama-tama ia akan mencapai proksi, yang disebut ConventionsLocator , yang menggunakan API refleksi standar untuk memeriksa apakah anotasi target ada. Ia akan memeriksa konvensi hanya jika ia tidak menemukan anotasi kerangka kerja dengan cara lain yang memungkinkan. Ketika elemen kode memiliki anotasi kerangka kerja, anotasi kerangka kerja ini selalu memiliki prioritas atas konvensi. Jika anotasi target tidak ada, maka kode harus memverifikasi apakah anotasi konvensi dikaitkan dengan anotasi target dan apakah elemen kode cocok dengan konvensi yang ditentukan oleh anotasi konvensi. Jika jawabannya positif, proksi harus mengembalikan respons yang sama seolah-olah anotasi target ada di sana. Untuk menemukan konvensi yang dikaitkan dengan anotasi kerangka kerja, komponen ConventionsLocator memeriksa repositori tempat konvensi ini direpresentasikan dan disimpan. Model kami juga mengusulkan untuk mendefinisikan konvensi dalam definisi anotasi target menggunakan anotasi konvensi.

Struktur yang disajikan dalam Gambar 2 didasarkan pada pola Metadata Repository [ 12 ], yang kelas-kelas yang berpartisipasinya disorot oleh stereotip dengan nama yang sama. Pola ini membuat repositori untuk menyimpan metadata saat runtime, menghindari pembacaan metadata yang tidak perlu dan, dalam kasus ini, merangkum identifikasi konvensi. Kelas ConventionsContainer memainkan peran Metadata Container, dan kelas ConventionsRepository menyimpan contohnya, yang menyediakan metadata yang terkait dengan konvensi ke ConventionsLocator . ConventionsContainer mewakili semua konvensi yang terkait dengan anotasi target. Dalam model kami, konvensi hadir dalam definisi anotasi target. Anotasi konvensi mendefinisikan konvensi yang menandai anotasi target (yang dihilangkan saat elemen cocok dengan konvensi). Kelas pembaca akan memuat metadata ini dan menambahkannya ke repositori.

Satu tantangan terhadap transparansi pendekatan ini adalah dalam skenario di mana perlu mengembalikan anotasi kerangka kerja. Untuk transparansi ini, API pembacaan metadata harus mengembalikan anotasi target bahkan ketika hanya konvensi yang ada. Kesulitannya adalah tidak mungkin untuk membuat instance anotasi di Java, dan satu-satunya cara untuk mengambilnya adalah dari elemen kode sumber yang sudah memilikinya. Sebagai strategi untuk mengatasi keterbatasan ini, kelas dengan anotasi target dibuat saat runtime menggunakan manipulasi bytecode. Setelah itu, kelas yang dimuat menerima anotasi target, dan anotasi target diambil dan dikembalikan. Gambar 3 menyajikan langkah-langkah yang diusulkan oleh model ini untuk mencapainya. Pertama, klien aplikasi mencapai ConventionsLocator , yang harus memeriksa apakah elemen tersebut cocok dengan konvensi. Jika gagal memeriksa keberadaan anotasi target, ia harus memeriksa apakah konvensinya cocok. Jika elemen kode cocok dengan konvensi, ConventionsLocator harus meminta BytecodeManipulator untuk membuat dan memuat kelas dengan anotasi target. Kemudian, ConventionsLocator menggunakan Reflection API untuk membaca anotasi target dari kelas yang dihasilkan oleh BytecodeManipulator dan mengembalikan contoh ini ke klien aplikasi.

4 Dukungan Metadata Esfinge untuk Konvensi Melalui Konfigurasi
Esfinge Metadata dikembangkan untuk mendukung proses membaca dan memvalidasi metadata [ 17 , 18 ]. Tidak seperti Java Reflection API, yang hanya menyediakan metode untuk mengambil anotasi dari elemen kode, Esfinge Metadata API menggunakan Metadata Mapping [ 58 ] untuk memetakan informasi pada anotasi kelas ke atribut suatu objek. Informasi ini berguna untuk menjaga metadata ini saat runtime [ 19 ]. Strukturnya memandu pengembang untuk mengimplementasikan pola kerangka kerja berbasis metadata dan praktik terbaik [ 12 , 13 ]. Berdasarkan studi evaluasi yang dilakukan, API ini memandu desain kerangka kerja ke evolusi yang lebih konsisten, dengan lebih sedikit kompleksitas dan lebih sedikit ketergantungan antar modul [ 19 ]. Esfinge Metadata menyediakan beberapa alternatif untuk mengambil metadata yang didefinisikan dalam anotasi. Bagian ini tidak menjelaskan API lengkapnya tetapi hanya bagaimana konvensi didefinisikan dan digunakan. Fungsionalitas yang baru diimplementasikan kompatibel dengan semua fitur Esfinge Metadata lainnya. Untuk informasi lebih lanjut tentang pengambilan anotasi, lihat makalah penelitian tentang pendekatan pembacaan metadata baru [ 18 , 19 ].

4.1 Menetapkan Konvensi untuk Anotasi
Dalam pendekatan kami, untuk menentukan konvensi untuk anotasi target, kami menambahkan anotasi konvensi dalam definisinya, dalam kasus kami, dari Esfinge Metadata, yang menentukan konvensi yang diinginkan. Untuk menghindari kebingungan, kami menggunakan “anotasi target” atau “anotasi kerangka kerja” untuk merujuk ke yang menerima konvensi dan “anotasi konvensi” untuk merujuk ke yang dari API pembacaan metadata yang menentukan konvensi.

Anotasi konvensi harus dikonfigurasi di setiap anotasi target untuk menggunakan pendekatan kami untuk konvensi atas konfigurasi. Daftar 1 menyajikan anotasi target @IsParameterPresent . Anotasi target ini memiliki anotasi konvensi @SuffixConvention . Dengan mengonfigurasi anotasi target @IsParameterPresent dengan anotasi konvensi @SuffixConvention(value = “Present”) (baris 3), setiap elemen bidang yang namanya diakhiri dengan sufiks “Present” akan secara implisit dianggap dikonfigurasi dengan anotasi target @IsParameterPresent .

Perhatikan Listing 2, kolom “valuePresent” (baris 2) dan “value” (baris 4) keduanya dikonfigurasi dengan anotasi target @IsParameterPresent karena “value” diberi anotasi secara eksplisit dan “valuePresent” diakhiri dengan sufiks yang dikonfigurasi oleh anotasi konvensi. Meskipun anotasi kerangka kerja @IsParameterPresent tidak secara eksplisit mengonfigurasi anggota “valuePresent” (baris 2), Metadata Esfinge dapat mendeteksi konvensi dan membaca anotasi seolah-olah ada di sana.

4.2 Memperluas Kerangka Kerja untuk Menentukan Konvensi Baru
Daftar 3 menyajikan contoh tentang bagaimana kerangka kerja mendefinisikan konvensi. Kebijakan penyimpanan anotasi konvensi harus ditetapkan ke waktu proses (baris 1), dan elemen target harus berupa tipe anotasi (baris 2). Anotasi @Verifier mengonfigurasi kelas terkait yang harus dipanggil oleh Esfinge Metadata API untuk memverifikasi apakah elemen kode target cocok dengan konvensi (baris 3). ConventionVerifier adalah kelas konkret yang memverifikasi apakah elemen kode cocok dengan konvensi. Daftar 4 menyajikan antarmuka ConventionVerifier , yang diimplementasikan oleh setiap kelas yang bertanggung jawab untuk memverifikasi keberadaan konvensi. Metode init bertanggung jawab untuk memproses parameter atau anotasi konvensi, dan metode isConventionPresent memverifikasi apakah AnnotatedElement cocok dengan konvensi.

Anotasi konvensi dapat memiliki atribut, seperti nilai dalam kasus ini, untuk membuat parameter pada konvensi. Misalnya, anotasi konvensi SuffixConvention menerima String value() , yang menetapkan bahwa nama elemen kode harus diakhiri dengan sehingga elemen tersebut sesuai dengan konvensi. Pertimbangkan Listing 5 di mana kami menyajikan implementasi SuffixConventionVerifier . Metode init bertanggung jawab untuk membaca nilai untuk anotasi konvensi sufiks (baris 4). Kemudian, ketika keberadaan konvensi harus diverifikasi, metode isConventionPresent (baris 8) membaca nama AnnotatedElement dan memeriksa apakah nama elemen diakhiri dengan sufiks yang ditetapkan dalam anotasi konvensi.

4.3 Konvensi untuk Nilai Atribut Anotasi
Jika satu anotasi kerangka kerja memiliki atribut, pengembang dapat membuat anotasi pada atributnya untuk menentukan nilai mana yang akan dimiliki atribut anotasi kerangka kerja jika elemen kode cocok dengan konvensi. Daftar 6 menyajikan anotasi @Configurable untuk menerima nilai yang muncul sebelum sufiks “Config” pada atribut “name()”. @FixedStringValue adalah anotasi konvensi atribut yang menentukan nilai atribut name() dari anotasi @Configurable saat elemen kode cocok dengan konvensi anotasi target @Configurable .

Misalnya, pertimbangkan bahwa aplikasi tersebut meminta untuk mengambil anotasi kerangka kerja @Configurable dalam suatu metode tanpa anotasi target yang dikonfigurasi secara eksplisit. Pertimbangkan bahwa metode tersebut sesuai dengan konvensi yang ditetapkan oleh anotasi konvensi tersebut–anotasi tersebut kembali dengan nilai yang ditetapkan dalam atribut masing-masing. Pertimbangkan kelas ConfigValues ​​yang dideklarasikan dalam Daftar 7. Metode bernama userConfig() , yang sesuai dengan konvensi karena memiliki sufiks “Config,” akan memiliki nilai untuk nama atribut tersebut sebagai nilai “defaultName” .

4.4 Ekstensi untuk Konvensi Atribut Baru
Mekanisme konvensi atribut dapat dibuat serupa dengan memperluas anotasi konvensi baru. Perlu dibuat anotasi untuk mengonfigurasi konvensi atribut dan kelas konkret yang mengimplementasikan antarmuka AtributeConventionValueGenerator untuk menyediakan konvensi atribut baru. Kelas konkret ini harus berisi logika yang menghasilkan nilai yang diinginkan untuk parameter anotasi.

Daftar 8 menyajikan deklarasi konvensi atribut @FixedStringValue . Seperti konvensi lainnya, konvensi atribut memiliki kebijakan penyimpanannya sendiri, yang harus berupa runtime (baris 1), dan elemen target harus berupa metode (baris 2). Setiap konvensi atribut memiliki generatornya sendiri yang terkait (baris 3). Kemudian, nilai FixedStringGenerator.class merupakan implementasi konkret dari generator untuk anotasi @FixedStringValue .

Daftar 9 menyajikan implementasi kelas FixedStringGenerator . Antarmuka AtributeConventionVerifier memiliki satu metode tunggal ( generateValue ) yang bertanggung jawab untuk menghasilkan nilai untuk konvensi atribut. Dalam hal ini, generator harus mengembalikan nama elemen yang sesuai dengan konvensi.

4.5 Menemukan Konvensi untuk Anotasi
Esfinge Metadata API mengimplementasikan pola desain Metadata Reader Chain untuk memverifikasi apakah elemen kode sesuai dengan konvensi karena, dengan pola ini, sumber yang berbeda dapat membaca metadata. Karena pendekatan kami menggunakan anotasi konvensi untuk menentukan konvensi, kami mengimplementasikan, dalam Esfinge Metadata API, kelas ConventionsLocator yang memperluas MetadataReader , yang bertanggung jawab untuk memverifikasi apakah elemen kode sesuai dengan konvensi. Singkatnya, ConventionsLocator membangkitkan rantai penentu lokasi metadata yang disediakan oleh Esfinge Metadata API. Menurut Listing 10, rantai tersebut membangkitkan pembaca untuk menemukan metadata.

Kelas LocatorsFactory bertanggung jawab untuk membuat rantai MetadataLocator . Setiap locator bertanggung jawab untuk mencari metadata dengan cara yang berbeda. Sebelum menjalankan logikanya, setiap locator akan terlebih dahulu memanggil locator berikutnya dari rantai tersebut, yang berarti bahwa ia hanya akan mencari metadata jika locator berikutnya tidak menemukan metadata. Itu berarti ConventionsLocator memverifikasi apakah elemen tersebut cocok dengan konvensi hanya jika semua locator lain dari rantai tersebut tidak menemukan metadata. Ketika locator lain tidak menemukan anotasi, ConventionsLocator menggunakan verifikator konvensi yang ditentukan oleh anotasi konvensi untuk memverifikasi apakah elemen kode tersebut cocok dengan konvensi. Locator berikutnya adalah InsideAnnotationsLocator , yang mencari metadata di dalam anotasi target. Mengikuti rantai tersebut, EnclosingElementLocator mencari metadata pada elemen yang melampirkan elemen kode yang dikonfigurasi. Misalnya, jika suatu bidang memiliki anotasi target, EnclosingElementLocator juga mencari metadata dalam deklarasi kelas. Esfinge Metadata API menyediakan InheritanceLocator untuk mencari metadata pada antarmuka dan superkelas suatu kelas. Terakhir, API memiliki RegularLocator untuk memeriksa apakah elemen kode memiliki metadata.

Bahasa Indonesia: Ketika elemen kode cocok dengan konvensi, mengembalikan instans dari anotasi target yang sesuai adalah perlu. Gambar 4 menyajikan cara mengembalikan instans dari anotasi target pada waktu proses. MetadataReaderClient , yang mewakili kelas yang perlu membaca metadata, meminta ConventionsLocator untuk instans dari anotasi kerangka kerja tersebut jika elemen kode cocok dengan konvensi. Jika anotasi target tidak ada dalam elemen kode, penentu lokasi memeriksa apakah elemen cocok dengan konvensi yang ditetapkan dalam anotasi kerangka kerja. Jika cocok, penentu lokasi meminta kelas AnnotatedElementUtils untuk menghasilkan bytecode dari kelas dengan anotasi target yang digunakan sebagai sumber pada waktu proses. AnnotatedElementUtils menggunakan Esfinge ClassMock [ 59 ], kerangka kerja yang menghasilkan kelas pada waktu proses menggunakan manipulasi bytecode, untuk menghasilkan kelas yang dikonfigurasi dengan anotasi target. Setelah mendapatkan kelas yang dihasilkan dari Esfinge ClassMock, AnnotatedElementUtils mengambil contoh anotasi masing-masing dan mengembalikannya ke penentu lokasi konvensi.

5 Studi Kasus Perbandingan Esfinge
Esfinge Comparison [ 12 ] adalah kerangka kerja berbasis metadata sumber terbuka untuk membandingkan dua contoh dari kelas yang sama. Kerangka kerja ini menyediakan anotasi untuk menyesuaikan cara kerja algoritma perbandingan antara contoh-contoh tersebut. Untuk pemahaman yang lebih baik, pertimbangkan istilah “anotasi perbandingan” sebagai anotasi yang digunakan untuk menyesuaikan algoritma perbandingan. Kerangka kerja ini mendukung perbandingan properti objek atau antara daftar objek yang kompleks. Kerangka kerja ini dapat diperluas, yang memungkinkan pengembang untuk membuat anotasi dan kelas baru untuk membaca dan memproses metadata.

Anotasi perbandingan mengonfigurasi metode pengambil kelas. Kerangka kerja mencari semua atribut kelas (publik atau privat) karena menggunakan pengambil kelas untuk mengaksesnya. Anotasi target kerangka kerja menyesuaikan algoritme perbandingan. Setiap anotasi kerangka kerja memiliki anotasi @DelegateReader , yang menentukan kelas yang bertanggung jawab untuk menjalankan algoritme perbandingan untuk anotasi target tersebut. Beberapa anotasi kerangka kerja yang kami tambahkan konvensinya tercantum di bawah ini.

1. @IgnoreInComparison : anotasi kerangka kerja ini menentukan bidang yang tidak berpartisipasi dalam perbandingan instans.
2. @DeepComparison : mengeksekusi perbandingan properti, membandingkan properti internalnya.
3. @Tolerance : mengonfigurasi toleransi numerik yang diizinkan untuk suatu atribut. Anotasi target ini mengonfigurasi atribut floating point, yang dapat muncul sebagai perbedaan yang disebabkan oleh batas bawah atau batas atas.

Studi kasus ini bertujuan untuk mengidentifikasi upaya untuk melakukan refaktor kerangka kerja perbandingan guna mendukung konvensi kode menggunakan pendekatan yang diusulkan. Karena Esfinge Comparison menggunakan Esfinge Metadata sebagai API pembacaan metadata-nya, kami memutuskan untuk meningkatkan kerangka kerja tersebut dengan menambahkan dukungan untuk konvensi untuk beberapa anotasi perbandingannya. Untuk memastikan bahwa pendekatan kami mencapai tujuannya, satu-satunya modifikasi yang diperlukan untuk menambahkan konvensi adalah mengonfigurasi anotasi konvensi dalam anotasi kerangka kerja.

Tabel 1 menyajikan anotasi konvensi yang ditambahkan ke anotasi target kerangka perbandingan. Untuk anotasi target @IgnoreInComparison , kami menambahkan anotasi konvensi @PrefixConvention(value = “getIgnore”) ; dengan cara ini, setiap metode pengambil dengan nama yang dimulai dengan “getIgnore” tidak akan memiliki atribut pengembalian yang dipertimbangkan dalam perbandingan. Untuk anotasi kerangka @DeepComparison , kami menambahkan @SuffixConvention(value = “Deep”) ; bentuk ini, semua metode pengambil yang diakhiri dengan “Deep”, akan dianggap memiliki anotasi target @DeepComparison . Akhirnya, untuk anotasi target @Tolerance, anotasi konvensi @MethodReturnTypeConvention(double.class) diterapkan; dengan cara ini, semua pengambil yang mengembalikan nilai ganda akan dianggap memiliki anotasi @Tolerance , dengan nilai toleransi default 0,01. Perhatikan bahwa untuk anotasi kerangka kerja @Tolerance , kami juga menambahkan konvensi atribut @FixedDoubleValue ke parameter value() .

TABEL 1. Konvensi yang digunakan untuk anotasi perbandingan.

Pengujian integrasi otomatis ditambahkan ke rangkaian pengujian kerangka kerja untuk mengevaluasi apakah konvensi baru dipertimbangkan dalam fungsionalitas kerangka kerja dan selaras dengan tujuan studi kasus untuk menerapkan konvensi. Satu-satunya perubahan adalah penambahan anotasi konvensi ke anotasi kerangka kerja yang ada.

Misalnya, perhatikan Daftar 11 yang menyajikan kode untuk anotasi kerangka @Tolerance sebelum pemfaktoran ulang untuk menambahkan dukungan konvensi, dan Daftar 12 kode yang difaktorkan ulang. Untuk mendukung konvensi, @MethodReturnTypeConvention mengonfigurasi konvensi, dan @FixedDoubleValue nilai toleransi jika konvensi terverifikasi. Demikian pula, anotasi konvensi lainnya ditambahkan sebagaimana didefinisikan dalam Tabel 1 .

Setelah perubahan ini, semua pengujian integrasi otomatis, termasuk yang baru untuk memverifikasi konvensi baru, berhasil dijalankan. Karena kami menerapkan konvensi dengan menambahkan anotasi konvensi ke anotasi kerangka kerja, kami mengonfirmasi bahwa solusi kami memenuhi tujuannya. Kode sumber lengkap dari studi kasus ini tersedia di repositori Github kerangka kerja Perbandingan Esfinge 1 , di cabang “konvensi”, tempat semua perubahan dan pengujian dapat diakses.

6 Desain Studi Evaluasi
Untuk mengevaluasi model yang kami usulkan di Bagian 3 , kami melakukan percobaan dengan menjawab Pertanyaan Penelitian (RQ) berikut:

RQ: Bagaimana model yang diusulkan untuk implementasi Konvensi atas Konfigurasi memengaruhi pengembangan kerangka kerja berbasis metadata? Untuk menjawab pertanyaan tersebut, pertama-tama, kami mengimplementasikan model yang disajikan di Bagian 3 pada Esfinge Metadata API. Kami merancang tugas pemrograman bagi para peserta untuk mengimplementasikan konvensi dalam kerangka kerja subjek yang ada. Kami merancang empat tugas, artinya kami memiliki empat konvensi yang berbeda tetapi dengan perilaku yang serupa. Para peserta harus mengimplementasikan tugas-tugas tersebut dalam implementasi yang dibuat hanya dengan pendekatan Reflection API dan yang lain yang menggunakan Esfinge Metadata API. Setelah menyelesaikan tugas-tugas tersebut, para peserta menjawab kuesioner evaluasi. Kami kemudian menganalisis solusi mereka, mengamati perubahan yang dibuat pada kode.

Subbagian berikut menyajikan kerangka kerja yang digunakan dalam percobaan tersebut, disebut sebagai kerangka kerja subjek yang digunakan dalam penelitian ini, dan menguraikan tugas-tugas yang dilaksanakan oleh peserta.

6.1 Desain Eksperimen
Pada langkah pertama pekerjaan kami, salah satu peneliti menerapkan kerangka subjek untuk evaluasi. Kerangka subjek adalah kerangka berbasis metadata untuk memetakan argumen baris perintah ke instance kelas, merujuk pada spesifikasi yang tepat yang digunakan dalam studi lain [ 19 ]. Kedua, kami menyiapkan dokumentasi untuk Esfinge Metadata API dan kerangka subjek. Para peserta dapat mengakses dokumentasi ini saat mengimplementasikan tugas untuk mendukung pengembangan. Kemudian, kami menyiapkan deskripsi untuk tugas para peserta. Setiap peserta memiliki akses ke dua repositori GitHub, tempat kami menyediakan implementasi kerangka subjek dan tempat solusi mereka harus didorong. Repositori bersifat pribadi, dan para peserta memiliki akses eksklusif ke dua repositori mereka. Kami melakukan dua eksperimen percontohan dengan dua anggota kelompok penelitian untuk mengevaluasi dokumentasi kami dan menguji apakah repositori tersebut memenuhi konfigurasi yang benar. Percontohan tidak dipertimbangkan dalam evaluasi akhir tetapi berfungsi untuk meningkatkan dokumentasi dan memastikan bahwa para peserta tidak menghadapi kesalahan konfigurasi repositori.

Kami melaksanakan percobaan di kelas yang terdiri dari 28 siswa yang mencoba melaksanakan tugas dan menjawab kuesioner. Kami membagi siswa menjadi empat kelompok yang masing-masing terdiri dari 7 siswa. Kelompok-kelompok tersebut dijelaskan dalam Tabel 2. Kelompok-kelompok tersebut mengklasifikasikan siswa relatif terhadap konvensi yang diterapkan dan pendekatan yang digunakan. Tugas-tugas tersebut dirinci dalam Tabel 3. Setelah menerapkan tugas-tugasnya, para peserta menjawab kuesioner daring. Kami mengevaluasi kode sumber yang didorong oleh para peserta ke repositori GitHub, menganggapnya benar jika semua pengujian unit lulus dan para peserta menerapkan tugas-tugas dengan pendekatan yang benar. Solusi dengan kesalahan kompilasi gagal dalam pengujian atau diterapkan tanpa mengikuti spesifikasi untuk analisis kebenaran. Kami kemudian mengevaluasi perubahan yang dilakukan oleh para peserta, dengan mempertimbangkan hanya siswa yang berhasil menerapkan tugas-tugas dengan benar. Langkah terakhir adalah mengevaluasi respons kuesioner berdasarkan pengalaman para peserta dengan kesulitan, keuntungan, dan kerugian saat menerapkan konvensi dengan kedua pendekatan.

TABEL 2. Distribusi kelompok peserta.

TABEL 3. Deskripsi tugas.

Untuk menghindari bias partisipan, kami menggunakan desain crossover [ 60 ]. Desain ini menyarankan agar partisipan mengerjakan tugas mereka dalam urutan yang berbeda, mengurangi variabilitas hasil dan meningkatkan konfirmasi hasil. Dalam penelitian kami, partisipan yang berbeda harus mengimplementasikan dua konvensi yang berbeda menggunakan dua pendekatan yang berbeda, Reflection API dan Esfinge Metadata API. Namun, karena kami mengikuti desain crossover, beberapa partisipan diminta terlebih dahulu untuk mengimplementasikan konvensi menggunakan Reflection API. Sebaliknya, partisipan lain terlebih dahulu mengimplementasikan konvensi mereka dengan Esfinge Metadata API. Partisipan diminta untuk mengimplementasikan tugas dalam kerangka kerja yang berbeda. Misalnya, beberapa partisipan mengimplementasikan konvensi A dan B menggunakan Reflection API dan konvensi C dan D menggunakan Esfinge Metadata API. Di sisi lain, beberapa partisipan mengimplementasikan konvensi A dan B menggunakan Esfinge Metadata API dan konvensi C dan D menggunakan Reflection API.

Melakukan eksperimen dengan melibatkan mahasiswa merupakan pendekatan yang layak dan pilihan umum untuk memajukan bidang rekayasa perangkat lunak melalui studi empiris. Salman dkk. [ 61 ] menunjukkan bahwa pengembang dan mahasiswa memiliki kinerja yang sama saat bereksperimen dengan pendekatan baru. Dalam eksperimen kami, kami memberikan peserta implementasi lengkap dari kerangka kerja subjek, dengan serangkaian pengujian yang dua pengujiannya gagal. Pengujian yang gagal terkait dengan konvensi yang harus diimplementasikan. Dengan kata lain, peserta bereksperimen dengan pendekatan baru.

6.2 Deskripsi Kerangka Evaluasi
Bahasa Indonesia: Kami menyediakan partisipan dengan dua versi kerangka kerja subjek untuk mengevaluasi model yang diusulkan di Bagian 3 , satu menggunakan Esfinge Metadata API dan yang lainnya hanya menggunakan Reflection API. Versi yang tepat dikembangkan untuk studi sebelumnya yang membandingkan penggunaan kedua API ini [ 19 ], dan kedua implementasi memiliki rangkaian pengujian yang sama. Rangkaian pengujian ini terdiri dari 67 pengujian unit untuk memastikan kerangka kerja subjek dapat memproses anotasi target dengan benar. Kerangka kerja subjek ini memetakan larik parameter dari baris perintah ke kelas menggunakan anotasi kerangka kerja. Larik parameter ini diterima dalam metode main() dan dipetakan ke kelas JavaBean. Pemetaan ini dilakukan melalui konfigurasi metadata menggunakan anotasi kerangka kerja.

Kerangka kerja subjek ini mengimplementasikan pola Metadata Container [ 12 ], dengan struktur dasarnya disajikan pada Gambar 5. Pola Metadata Container memperkenalkan kelas yang disebut MetadataContainer , yang instansinya mewakili metadata yang dibaca saat runtime. Kelas ini bertanggung jawab untuk menyimpan metadata yang dibaca dari anotasi kerangka kerja. Kelas FrameworkController meminta repositori untuk metadata dari kelas yang ditentukan. Jika metadata belum diambil, repositori harus memanggil MetadataReader untuk menemukan metadata. Anotasi kerangka kerja yang digunakan untuk percobaan ini adalah:

1. @IsParameterPresent(String paramName) : Anotasi kerangka kerja ini menetapkan atribut boolean kelas sebagai benar atau salah jika parameter paramName ada di baris perintah.
2. @ParameterPrecision(int desimalPlaces) : Anotasi kerangka kerja ini mengonfigurasi toleransi desimal untuk bidang bertipe float atau double. Misalnya, jika nilai desimalPlaces adalah 2, nilai parameter tidak boleh memiliki lebih dari dua tempat desimal.
3. @TextValue(String value) : Atribut String yang dianotasi dengan anotasi kerangka kerja ini akan menerima nilai string sebagai nilainya.
4. @CompositeParameter : Anotasi kerangka kerja ini memetakan nilai untuk bidang bertipe non-primitif, yaitu kelas lain.

   

   

Kami menyediakan implementasi konkret kelas ParamMapper kepada para peserta. Kami menghilangkan kode tersebut karena kode tersebut sangat panjang. Daftar 13 menyajikan kelas paramMapper. Kelas ParamMapper bertanggung jawab untuk memetakan parameter yang diterima dari baris perintah ke instance dari instance kelas. Metode utama, map , mengembalikan instance kelas. Metode readMetadata membuat kontainer dengan parameter. Metode readParameters bertanggung jawab untuk memproses kontainer parameter dan menggunakan informasinya untuk membuat instance kelas. Kelas ParamMapperContainer juga disediakan kepada para siswa. Kelas ini adalah kontainer dengan parameter yang diterima oleh kelas paramMapper.

6.2.1 Tugas
Peserta harus menerapkan dua konvensi yang berbeda tetapi serupa untuk setiap versi kerangka subjek. Dengan dua pendekatan yang berbeda terhadap kerangka subjek, kami dapat membandingkan kode yang dihasilkan dan mengumpulkan umpan balik peserta tentang pengalaman mereka mengembangkan konvensi atas konfigurasi untuk setiap skenario. Kami membagi tugas menjadi dua kelompok A dan B menurut Tabel 3. Setiap kelompok tugas, A dan B, memiliki dua tugas. Kolom “Konvensi yang Akan Diimplementasikan” menyajikan deskripsi tugas yang akan dilakukan siswa. Siswa harus meningkatkan metode readParameters , memeriksa apakah atribut kelas cocok dengan konvensi tertentu. Misalnya, jika seorang peserta harus mengimplementasikan Tugas 1 dari Kelompok A, maka peserta ini harus menulis kode untuk memeriksa apakah tipe bidang kelas adalah boolean dan apakah namanya diakhiri dengan “Hadir”. Jika atribut kelas cocok dengan konvensi, maka bidang boolean yang cocok dengan konvensi harus dipakai dengan nilai parameter.

6.3 Repositori Kode
Repositori untuk setiap peserta, satu berisi implementasi menggunakan Esfinge Metadata API dan yang lain menggunakan Reflection API, milik organisasi GitHub. 2 Setiap peserta hanya memiliki akses ke repositori privat mereka. Misalnya, nama repositori seperti ParticipantsOne-metadata (repositori Esfinge Metadata) dan ParticipantsOne-reflection (repositori Reflection), di mana ParticipantsOne adalah nama pengguna GitHub peserta. Repositori dari peserta lain tidak terlihat oleh ParticipantsOne . Peserta memiliki akses untuk melakukan komitmen dan menarik kode sumber, dan solusi mereka harus didorong ke repositori yang benar. Misalnya, kode yang ada di ParticipantsOne-reflection harus berisi implementasi tugas yang dilakukan oleh ParticipantsOne menggunakan Reflection API. Kami menggunakan kode yang ada di repositori ini untuk mengevaluasi solusi peserta.

6.4 Dokumentasi
Sebelum menerapkan konvensi kode, para peserta diberikan seperangkat instruksi tentang cara menjalankan setiap tugas. Instruksi percobaan memberikan informasi tentang urutan pelaksanaan tugas, cara mengakses dokumentasi, cara mengakses repositori kode, dan cara mengakses deskripsi tugas. Selain itu, mereka memiliki akses ke dokumentasi tentang Esfinge Metadata API dan kerangka kerja subjek tempat konvensi perlu diterapkan. Saat menjalankan tugas, para peserta diizinkan untuk beristirahat dan mencari sumber informasi lain untuk membantu menerapkan tugas. Kami menganggap membaca dokumentasi dan menerapkan konvensi sebagai total waktu yang diperlukan untuk menyelesaikan tugas.

6.5 Desain Kuesioner
Kuesioner ini terdiri dari dua bagian. Bagian pertama menanyakan keakraban peserta dengan anotasi dan bahasa pemrograman utama mereka. Di bagian kedua, peserta ditanya tentang pengalaman mereka secara keseluruhan dan pendekatan terhadap evaluasi. Tabel 4 menyajikan pertanyaan-pertanyaan dari bagian kedua kuesioner. Pertanyaan-pertanyaan
Q
1
–
Q
9
ditanyakan dua kali, satu kali untuk pengalaman penerapan dengan Reflection API dan satu kali untuk Esfinge Metadata API. Terakhir, serangkaian 6 pertanyaan diajukan kepada peserta, di mana kami meminta mereka untuk mengevaluasi setiap pendekatan.

TABEL 4. Pertanyaan kuesioner.

Rangkaian pertanyaan pertama menanyakan peserta tentang kelebihan dan kekurangan mengembangkan konvensi kode dengan setiap kerangka kerja. Pertanyaan Q6 memiliki delapan opsi default yang disajikan dalam Tabel 5, tempat peserta dapat memilih semua kesulitan yang ditemukan dan satu bidang terbuka bagi pengguna untuk menginformasikan kesulitan lain yang tidak ada dalam daftar default. Opsi OPT2 dan OPT5 memiliki teks yang sedikit dimodifikasi karena opsi tersebut terkait dengan penggunaan kerangka kerja. Pertanyaan Q4 dan Q8 dari bagian pertama adalah pertanyaan terbuka opsional dan hanya dijawab ketika peserta menjawab “ya” untuk pertanyaan Q3 dan Q7, berturut-turut. Pertanyaan Q1 dan Q3 dari bagian kedua memiliki serangkaian kemungkinan jawaban default, disajikan dalam Tabel 5 , dan satu bidang terbuka tempat peserta dapat menyatakan kelebihan lain dari setiap kerangka kerja. Peserta harus menjawab kekurangan setiap kerangka kerja pada pertanyaan Q2 dan Q4 dari bagian kedua kuesioner dan pilihan mereka disajikan dalam Tabel 5. Akhirnya, Q5 menanyakan kerangka kerja mana yang akan dipertimbangkan peserta untuk digunakan untuk mengembangkan kerangka kerja berbasis metadata, dan Q6 adalah satu pertanyaan terbuka wajib tempat peserta harus membenarkan jawaban sebelumnya.

TABEL 5. Pilihan untuk pertanyaan evaluasi pendekatan.

7 Hasil
Bagian ini menyajikan data yang dikumpulkan dari kuesioner yang dijawab oleh peserta. Kami mulai menjelaskan pelaksanaan eksperimen dan mengevaluasi kebenaran kode yang diterapkan oleh peserta. Kemudian, kami menyajikan waktu penerapan yang diperlukan untuk kedua pendekatan dan beberapa potongan kode solusi yang disajikan oleh peserta. Kemudian, kami menyajikan kelebihan, kekurangan, dan kesulitan. Kami menggunakan hasil yang disajikan di bagian ini untuk menjawab pertanyaan penelitian kami.

7.1 Pelaksanaan Percobaan
Kami menjalankan percobaan dengan mengikuti langkah-langkah pada Gambar 6. Dari 28 peserta yang mengajukan diri, satu orang tidak menerima undangan repositori. Dari 27 peserta yang menerima undangan, 23 orang berpartisipasi dalam percobaan, mengimplementasikan solusi mereka untuk tugas-tugas tersebut. Dua orang peserta memodifikasi pengujian unit, jadi kami menghapusnya dari hasil karena instruksi tersebut mengklarifikasi bahwa para peserta hanya boleh memodifikasi kode produksi, bukan pengujian kesatuan. Menganalisis kode sumber dari 21 peserta yang tersisa, kami menemukan bahwa satu orang peserta tidak mengimplementasikan tugas-tugas dengan benar dengan Esfinge Metadata yang mengalami kegagalan pengujian kesatuan. Kami melakukan analisis yang sama untuk kode sumber tugas-tugas Refleksi, dan kami melihat bahwa lima orang peserta tidak dapat menyelesaikan atau mengimplementasikan solusi-solusi dengan benar. Terakhir, tiga orang peserta tidak dapat mengimplementasikan beberapa atau semua tugas dengan benar untuk kedua kerangka kerja tersebut. Setelah langkah-langkah ini, 12 orang peserta berhasil mengimplementasikan semua tugas dengan benar.

7.2 Analisis Kebenaran
Menurut Gambar 6 , dengan hanya mempertimbangkan peserta yang berpartisipasi dalam percobaan, kami memiliki 12 peserta yang mengimplementasikan tugas dengan benar di kedua kerangka kerja. Kami memiliki lima peserta yang mengimplementasikan semua tugas menggunakan Esfinge Metadata API dengan benar tetapi gagal mengimplementasikan setidaknya satu tugas menggunakan Java Reflection API. Hanya satu peserta yang berhasil menyelesaikan tugas menggunakan Java Reflection API dan gagal mengimplementasikan tugas Esfinge dengan benar. Satu peserta gagal mengimplementasikan tugas dengan kedua pendekatan. Dua peserta memodifikasi pengujian unit, dan dua mengimplementasikan tugas yang kami minta untuk diimplementasikan dengan Esfinge Metadata API dengan Java Reflection API.

Kita dapat melihat bahwa jumlah peserta yang gagal menyelesaikan tugas refleksi (lima) lebih tinggi daripada jumlah peserta yang gagal mengimplementasikan tugas Metadata Esfinge (satu), yang berarti bahwa peserta mengalami kesulitan lebih besar dalam mengimplementasikan tugas dengan refleksi dalam eksperimen ini. Kami fokus pada pengalaman yang ditentukan untuk lebih memahami mengapa peserta mengalami kesulitan lebih besar dalam mengimplementasikan tugas dengan API Refleksi. Seorang peserta menyatakan bahwa meskipun memahami tugasnya, sulit untuk menavigasi kode. Selain itu, peserta menyatakan bahwa sulit untuk memahami kegagalan pengujian yang disebabkan oleh perubahan yang dilakukan pada kode. Analisis lebih lanjut dari kode peserta menunjukkan bahwa ia mencoba mengimplementasikan solusi pada logika pembacaan metadata dari kerangka kerja subjek. Perubahan mereka membuat kerangka kerja salah memproses beberapa jenis bidang, yang mengarah ke perilaku yang tidak diharapkan.

Peserta lain yang gagal mengimplementasikan tugas dengan refleksi menyatakan bahwa dokumentasi kerangka subjek tidak jelas, sehingga sulit untuk memahami kerangka subjek dan menemukan tempat untuk melakukan modifikasi. Peserta juga merasa bahwa ia dapat menyelesaikan tugas dengan dokumentasi yang lebih baik tentang kerangka subjek. Tiga peserta yang tersisa dari kelompok ini memberikan umpan balik tentang penyelesaian tugas. Namun, kode mereka masih mengalami kegagalan pengujian kesatuan, atau mereka hanya mengimplementasikan satu dari dua tugas karena mereka menghabiskan waktu 1 jam untuk mengimplementasikan tugas tersebut. Dengan menganalisis kode mereka, kami menemukan bahwa logika mereka untuk mengimplementasikan konvensi sudah benar untuk pengujian konvensi tetapi menghasilkan kegagalan dalam pengujian fungsionalitas kerangka, seperti bidang numerik yang menerima nilai String, yang menyebabkan kesalahan pengecualian. Meskipun mereka mengimplementasikan konvensi dengan benar, solusi mereka masih menampilkan kesalahan saat menjalankan pengujian kesatuan.

Peserta yang gagal menerapkan salah satu tugas dengan Esfinge Metadata menyatakan bahwa awalnya sulit dan membuat stres, tetapi hal ini diatasi dengan membaca dokumentasi. Karena peserta menghabiskan banyak waktu untuk membaca dokumentasi, ia tidak dapat menyelesaikan tugas tepat waktu. Dengan menganalisis kode, peserta melewatkan salah satu anotasi yang diperlukan untuk menyelesaikan tugas. Peserta menyatakan bahwa pesan kesalahan yang dihasilkan oleh API “tidak jelas” dan tidak membantu mengatasi kesalahan. Umpan balik ini dapat membantu para peneliti karena kami dapat memperbaiki pesan kesalahan yang dihasilkan oleh kesalahan implementasi untuk konvensi kode. Peserta menghadapi kesalahan ini karena tidak menambahkan anotasi atribut yang diperlukan untuk mengimplementasikan tugas. Peserta ini juga gagal mengimplementasikan satu tugas menggunakan API refleksi. Peserta menyatakan bahwa menavigasi kode boilerplate membuat frustrasi, dan sulit untuk memahami inti kerangka kerja, sehingga sulit untuk mengimplementasikan tugas. Terakhir, kami memiliki peserta yang tidak mengikuti petunjuk untuk eksperimen tersebut. Peserta memodifikasi pengujian unit, yang ditentukan untuk tidak dilakukan dalam petunjuk. Kami mempertimbangkan 12 peserta yang berhasil melaksanakan semua tugas dalam analisis kami.

Kami selanjutnya menyelidiki apakah bahasa pemrograman utama dan keakraban dengan anotasi kode memengaruhi ketepatan peserta. Tabel 6 menyajikan distribusi peserta menurut bahasa pemrograman utama dan keakraban dengan anotasi kode. Kami membandingkan apakah peserta yang menyatakan Java sebagai bahasa utama mereka lebih berhasil dalam mengimplementasikan tugas daripada peserta yang lebih menyukai bahasa pemrograman lain. Seperti yang dapat kita lihat, 7 peserta yang menyatakan Java sebagai bahasa utama mereka berhasil dalam mengimplementasikan tugas, dan 7 peserta yang juga menyatakan Java sebagai bahasa pemrograman utama mereka gagal dalam mengimplementasikan tugas. Lima peserta yang lebih akrab dengan bahasa pemrograman lain berhasil dalam mengimplementasikan tugas, sementara 4 lainnya gagal.

TABEL 6. Kebenaran menurut keakraban peserta dengan Java dan anotasi kode.

Kebenaran berdasarkan keakraban peserta dengan anotasi kode
Keakraban anotasi kode	Berhasil	Gagal
1	angka 0	1
2	4	2
3	3	4
4	4	4
5	1	angka 0

Dengan memperhitungkan keakraban anotasi kode, para peserta menyatakan keakraban mereka pada skala 1 sampai 5, dengan 1 tidak akrab dan 5 sangat akrab dengan anotasi kode. Satu-satunya peserta yang menyatakan keakrabannya sebagai 1 gagal dalam percobaan. Empat peserta yang tidak begitu akrab dengan anotasi kode berhasil dalam percobaan, sementara 2 gagal. Tiga peserta yang akrab dengan anotasi kode berhasil dalam tugas, dan 4 gagal. Empat peserta yang memiliki keakraban yang baik dengan anotasi kode berhasil, dan 4 peserta lain yang juga akrab dengan anotasi kode gagal melaksanakan tugas. Hanya satu peserta yang sangat akrab dengan anotasi kode berhasil melaksanakan tugas.

7.3 Waktu yang dihabiskan
Kami meminta peserta untuk mengukur total waktu yang dihabiskan untuk mengimplementasikan tugas mereka, yaitu waktu yang dibutuhkan untuk mengimplementasikan dua konvensi kode menggunakan setiap pendekatan. Kami juga meminta peserta untuk mempertimbangkan waktu yang dihabiskan untuk mengimplementasikan solusi, membaca dokumentasi yang disediakan, dan mencari materi tambahan. Gambar 7 menyajikan data. Untuk Esfinge Metadata API, waktu implementasi minimum adalah 2 menit, dan untuk Reflection API, minimumnya adalah 15 menit. Kami melihat bahwa 25% dari nilai untuk Esfinge Metadata API lebih rendah dari 23,75 menit dibandingkan dengan 21,75 untuk Reflection API. Median untuk Reflection API adalah 34,5 menit, dan Esfinge Metadata API memiliki median 28 menit. Tujuh puluh lima persen dari sampel Esfinge Metadata API memiliki waktu lebih rendah dari 36,25 dan 51 menit untuk Reflection API. Nilai tertinggi sama untuk kedua pendekatan karena satu peserta memberi tahu kami bahwa sekitar satu jam diperlukan untuk menyelesaikan tugas setiap kerangka kerja.

7.4 Baris Kode yang Dimodifikasi
Bahasa Indonesia: Setelah mengakses repositori kode, kami memeriksa kode sumber yang dihasilkan oleh para peserta. Tabel 7 menyajikan hasil yang dikumpulkan. Setiap kolom mewakili total baris kode yang diubah untuk mengimplementasikan konvensi dengan setiap pendekatan. Karena Esfinge Metadata API hanya mengandalkan penambahan anotasi, nilai maksimumnya adalah empat, dan minimumnya adalah tiga. Itu terjadi karena satu tugas hanya memerlukan satu anotasi untuk implementasinya. Untuk Reflection API, nilai maksimumnya adalah 14, dan minimumnya adalah tiga. Namun, karena baris kode Esfinge Metadata API hanya terdiri dari satu anotasi, baris-baris ini berisi lebih banyak elemen kode untuk Reflection API. Dengan mengamati Tabel 8 , kita dapat melihat bahwa baris kode Reflection memiliki lebih banyak elemen daripada Esfinge Metadata API. Misalnya, peserta P5, yang mengimplementasikan solusi dengan tiga baris kode, membuat 12 panggilan metode. Kami menyajikan beberapa cuplikan kode dengan solusi untuk setiap konvensi yang diimplementasikan oleh setiap peserta. Peserta P1 dan P3 mengimplementasikan tugas yang sama menggunakan Reflection API.

TABEL 7. Baris kode yang dimodifikasi oleh peserta.

TABEL 8. Elemen kode yang ada pada baris implementasi Refleksi.

Daftar 14 menyajikan implementasi konvensi untuk anotasi kerangka kerja @IsParameterPresent , dan Daftar 15 solusi dari partisipan P3. Baris yang diberi komentar dengan “kode yang ada” adalah baris kode yang ada sebelum refaktor partisipan, dan baris yang diberi komentar dengan “kode yang ditambahkan” adalah baris kode yang ditambahkan oleh partisipan untuk mengimplementasikan konvensi. Kita dapat melihat bahwa implementasinya serupa. Kode ini diimplementasikan dengan menggabungkan logika pembacaan metadata. Kedua partisipan mengandalkan Reflection API untuk mengimplementasikan konvensi dan menggunakan, dalam kasus ini, metode kelas String . Secara khusus, P3 menambahkan satu bidang tambahan untuk memverifikasi apakah sufiks tersebut ada. Selain itu, P3 mengimplementasikan metode pengambil untuk bidang ini. Kami memiliki implementasi kode yang berbeda untuk konvensi yang berbeda menggunakan Reflection API. Namun, implementasi dengan Esfinge Metadata API adalah standar.

Kami menyajikan pada daftar 16 implementasi dari konvensi yang sama tetapi menggunakan Esfinge Metadata. Peserta P2, P4, P6, P11, dan P12 membuat implementasi ini. Kami menyoroti bahwa peserta yang mengimplementasikan tugas anotasi kerangka kerja @IsParameterPresent menggunakan Reflection API tidak mengimplementasikan konvensi yang sama menggunakan Esfinge Metadata API. Dengan demikian, kami menyajikan solusi dari peserta yang berbeda. Karena pendekatan kami bergantung pada penyisipan anotasi konvensi pada anotasi kerangka kerja, setiap peserta yang mengimplementasikan konvensi dengan benar menghasilkan kode hasil yang sama. Peserta P2, P4, P6, P11, dan P12 mengubah tiga baris kode. Artinya, mereka menambahkan tiga anotasi untuk mengimplementasikan dua konvensi. Itu terjadi karena implementasi konvensi untuk anotasi kerangka kerja @CompositeParameter hanya membutuhkan satu anotasi, seperti yang disajikan dalam Daftar 17. Peserta P1, P3, P5, P7, P8, P9, dan P10 mengimplementasikan konvensi ini menggunakan Reflection API. Solusi mereka secara keseluruhan sangat mirip. Daftar 18 menyajikan implementasi konvensi untuk @CompositeParameter yang dibuat oleh peserta P5. Meskipun daftar menyajikannya dalam 4 baris, peserta menerapkan satu pernyataan “if”, yang memeriksa apakah parameter diberi anotasi dengan anotasi @OneToOne .

7.5 Kesulitan dan Kerugian
Kami mengumpulkan kesulitan dan kerugian yang dilaporkan yang dirasakan setiap peserta dalam melaksanakan tugas dengan setiap pendekatan dari kuesioner. Kami yakin kesulitan yang ditetapkan dapat membantu kami memahami mengapa peserta gagal melaksanakan tugas dengan menggunakan setiap pendekatan dengan sukses.

Peserta memberikan umpan balik tentang kesulitan mereka dalam mengimplementasikan tugas menggunakan pendekatan Esfinge Metadata API dan pendekatan Reflection API. Gambar 8 menyajikan kesulitan yang ditunjuk oleh peserta. Mengamati pengalaman peserta, kami mengamati delapan peserta menunjuk kurva pembelajaran yang diperlukan untuk Esfinge Metadata API. Kami memiliki tiga peserta yang menyatakan bahwa memahami tugas itu menantang. Tiga peserta menunjuk menemukan di mana untuk mengimplementasikan konvensi sebagai rumit. Mengimplementasikan fitur konvensi memiliki tiga jawaban. Tiga peserta menyatakan bahwa menavigasi dan memahami kerangka kerja target adalah suatu kesulitan. Terakhir, tidak ada peserta yang menunjuk tes unit sebagai kesulitan. Menurut Gambar 9 , kami memiliki 10 peserta yang menunjuk kurva pembelajaran sebagai kerugian. Hanya satu peserta yang menyatakan bahwa kode yang dihasilkan sulit untuk dipelihara dan lebih kompleks. Mengenai pengembangan, tiga peserta menyatakan bahwa sulit untuk dilakukan dan dua membutuhkan lebih banyak waktu untuk mengimplementasikan, dibandingkan dengan Reflection API.

 

Kesulitan yang paling menonjol mengenai Java Reflection API terkait dengan kode sumber. Sebanyak enam peserta menyatakan bahwa membaca dan menavigasi kode sumber sulit, dan empat menyatakan bahwa menemukan dan mengimplementasikan fitur konvensi kode sulit. Selain itu, empat peserta menyatakan bahwa menggunakan fitur refleksi menantang. Namun, seperti yang disajikan pada Gambar 9 , tujuh peserta menyatakan bahwa kode yang dihasilkan lebih sulit dipelihara. Kode yang dihasilkan lebih kompleks dan memiliki duplikasi yang ditunjuk oleh delapan peserta. Hanya satu peserta menyatakan bahwa diperlukan kurva pembelajaran yang signifikan. Pengembangan membutuhkan lebih banyak waktu dan ditunjuk oleh lima peserta. Terakhir, tiga peserta menyatakan bahwa pengembangan itu rumit.

7.6 Keunggulan Menggunakan Esfinge Metadata API Dibandingkan Reflection API
Gambar 10 menyajikan keunggulan kedua pendekatan tersebut. Enam peserta menyatakan bahwa implementasi dengan Reflection mudah dan tujuh untuk Esfinge Metadata API. Hanya dua yang menyatakan bahwa pendekatan Esfinge mudah dipelajari, dan lima menyatakan bahwa Reflection API mudah dipelajari. Perbedaan antara kedua pendekatan tersebut terkait dengan kode yang dihasilkan dan kecepatan pengembangan.

Sebagian besar peserta (10) menyatakan bahwa Esfinge Metadata API memiliki kecepatan pengembangan yang lebih cepat daripada Reflection API, sedangkan hanya tiga peserta yang menganggap kecepatan pengembangan sebagai keuntungan. Sembilan peserta juga menyatakan bahwa Esfinge Metadata API menghasilkan kode yang mudah diubah, dan dua untuk Reflection API. Peserta menyatakan bahwa keterbacaan kode Esfinge Metadata API juga lebih baik daripada Reflection API. Sebaliknya, sembilan peserta mengatakan kode dengan Esfinge Metadata API lebih mudah dibaca daripada dengan Reflection (satu).

7.7 Preferensi Kerangka Kerja
Dua pertanyaan kuesioner terakhir adalah tentang pendekatan yang disukai peserta untuk pengembangan. Menurut Gambar 11 , total 11 peserta lebih menyukai Esfinge Metadata API, dan satu lebih menyukai Reflection API. Sebagian besar peserta menganggap kurva pembelajaran yang diperlukan untuk menggunakan Esfinge Metadata API sulit. Menurut peserta, keterbacaan kode, kompleksitas yang lebih sedikit, dan kemudahan pemeliharaan adalah keuntungan dari Esfinge Metadata API. Reflection API dilaporkan mudah dipelajari, tetapi kode yang dihasilkan lebih kompleks dan lebih sulit dipelihara. Peserta menyatakan bahwa meskipun kurva pembelajaran yang diperlukan besar, mereka lebih menyukai Esfinge Metadata API. Pada awal pengembangan, dibutuhkan lebih banyak waktu untuk mempelajari dan menggunakan mekanisme konvensi kode. Mereka akan mempertimbangkan untuk menggunakan pendekatan Esfinge. Peserta P2 dan P9 menyatakan bahwa Esfinge Metadata API berkinerja lebih baik dalam keterbacaan kode bahkan dengan kurva pembelajaran yang signifikan. Peserta P9 juga menyatakan bahwa meskipun menantang pada tahap pengembangan awal, kerangka kerja mengungguli Reflection mengenai waktu pengembangan. Peserta P3, P6, P7, P9, dan P12 menyatakan bahwa meskipun terdapat kesulitan kurva pembelajaran, kode yang dihasilkan lebih mudah dibaca, lebih sedikit diduplikasi, dan lebih mudah dipelihara jika dibandingkan dengan kode yang dihasilkan dengan menggunakan Reflection API. Peserta P1 adalah satu-satunya peserta yang lebih menyukai Reflection API, tetapi peserta tersebut menyatakan bahwa ia akan mempertimbangkan untuk menggunakan Esfinge Metadata API daripada Reflection API untuk proyek yang lebih besar.

8 Diskusi
Pada bagian ini, kami membahas hasil yang disajikan pada Bagian 7 untuk menjawab pertanyaan penelitian kami. Untuk menjawab pertanyaan ini, kami mengevaluasi motif kegagalan peserta dalam mengimplementasikan tugas. Kemudian, kami menganalisis jawaban dari kuesioner tentang pengalaman mereka saat mengimplementasikan konvensi kode, dengan tujuan untuk memahami kesulitan yang dihadapi dan bagaimana hal itu memengaruhi pengembangan mereka. Kami juga menggunakan tanggapan mereka dari kuesioner untuk memahami apa yang memengaruhi waktu implementasi selama pelaksanaan eksperimen. Kami menggunakan umpan balik mereka untuk mengevaluasi keterbacaan dan pemeliharaan kode. Terakhir, kami menyajikan ancaman terhadap validitas kami.

8.1 Ketepatan Implementasi
Kami menganalisis kode sumber yang diberikan oleh peserta untuk menentukan apakah penerapan konvensi kode sudah benar. Kami mengecualikan peserta yang tidak dapat menerapkan konvensi tepat waktu atau menghasilkan kode yang tidak lulus semua pengujian unit dari analisis. Namun, kami menduga beberapa peserta tidak dapat menerapkan beberapa konvensi. Untuk menerapkan konvensi kode, peserta perlu membaca dokumentasi tentang Esfinge Metadata API, yang sebelumnya tidak diketahui oleh peserta. Untuk Reflection API, peserta mengalami kesulitan menavigasi dan memahami kode sumber.

Kita dapat mengekstrak beberapa informasi dari peserta yang gagal menerapkan konvensi kode. Hanya satu peserta yang gagal menerapkan konvensi kode menggunakan Esfinge Metadata API, tetapi tugas berhasil diterapkan menggunakan Reflection API. Total peserta yang gagal menerapkan tugas dengan Reflection API dan berhasil menerapkan tugas dengan Esfinge Metadata API adalah lima. Kemudian, kami mengevaluasi kesulitan yang diidentifikasi oleh keenam peserta. Peserta yang gagal menerapkan tugas dengan Esfinge Metadata API mengalami kesulitan memahami tugas. Peserta membuat beberapa kesalahan dengan repositori GitHub, mendorong kode Esfinge Metadata ke repositori kode Reflection. Setelah menyelesaikan kebingungannya dengan repositori kode, peserta menyatakan bahwa penerapan salah satu tugas dengan Esfinge Metadata API berlangsung cepat. Namun, menghabiskan begitu banyak waktu untuk memperbaiki masalah repositori membuat peserta kehabisan waktu untuk menyelesaikan tugas. Peserta menyatakan bahwa dokumentasi tentang Esfinge Metadata API bermanfaat untuk menyelesaikan tugas. Peserta ini berhasil menerapkan kedua tugas dengan Reflection API tetapi menyatakan bahwa perlu mempelajari kode lebih dalam. Meskipun gagal mengimplementasikan satu tugas dengan Esfinge Metadata API, peserta menyatakan bahwa menggunakan Esfinge Metadata API jauh lebih mudah daripada mengimplementasikan dengan Reflection dan menyatakan bahwa kebingungannya dengan repositori kode berkontribusi pada kegagalan tugasnya.

Peserta yang gagal menerapkan kedua pendekatan berhasil menerapkan satu tugas dengan Reflection dan tidak ada tugas dengan Esfinge Metadata API. Untuk tugas dengan Esfinge Metadata API, peserta menyatakan bahwa pesan kesalahan pengecualian dari Esfinge Metadata API tidak jelas. Saat memeriksa solusi peserta, kami menemukan bahwa peserta tidak memberikan anotasi konvensi atribut untuk tugasnya, yang menyebabkan kesalahan pengecualian penunjuk nol. Umpan balik ini dapat membantu kami memperbaiki pesan kesalahan dari Esfinge Metadata API. Peserta gagal menerapkan satu tugas dengan Reflection API. Membaca umpan baliknya, kami melihat bahwa menavigasi kode sumber membuang-buang waktunya dan sulit dipahami.

Dari lima peserta yang gagal menerapkan tugas dengan Reflection dan berhasil menerapkan dengan Esfinge Metadata API, alasan utamanya adalah menavigasi kode sumber, memahami di mana konvensi harus diterapkan, dan memahami dokumentasi tentang kerangka subjek. Alasan utama kegagalan adalah waktu implementasi, yang berarti para peserta menggunakan seluruh waktu mereka untuk menerapkan satu atau tidak ada tugas. Beberapa peserta dari kelompok ini menyatakan bahwa mereka menyelesaikan tugas, tetapi beberapa pengujian kesatuan masih gagal.

Untuk menyelidiki apakah bahasa pemrograman utama atau pengalaman dengan anotasi kode memengaruhi hasil kami, kami mengandalkan data yang disajikan dalam Tabel 6. Peserta yang menggunakan Java sebagai bahasa pemrograman utama memiliki tingkat keberhasilan dan kegagalan yang sama. Peserta yang menyatakan bahasa pemrograman lain lebih familiar memiliki hasil yang serupa; lima peserta berhasil, sementara 4 gagal. Karena sampel kami kecil, kami tidak dapat menggeneralisasi bahwa bahasa pemrograman tidak memengaruhi kesimpulan kami. Namun, hasil tidak menunjukkan bukti bahwa bahasa pemrograman memengaruhi secara positif atau negatif.

Pengalaman peserta dengan anotasi kode terjadi dalam analisis kebenaran. Seperti yang dapat kita lihat dari Tabel 6 , kami mendapati mayoritas peserta familier dengan anotasi tetapi bukan pakar atau sama sekali baru dalam fitur bahasa ini. Seperti yang dapat kita lihat dari hasil kami, peserta memiliki tingkat keberhasilan yang sama untuk kelompok perantara, dari “tidak begitu familier” hingga “sangat familier.” Mirip dengan pembahasan tentang bahasa pemrograman, kami tidak dapat menemukan bukti bahwa keahlian dengan anotasi kode memengaruhi hasil kami.

Hasil ini memenuhi harapan kami, meskipun para peserta tidak memiliki pengalaman sebelumnya dengan Esfinge Metadata API. Penerapan konvensi dengan Esfinge Metadata API bergantung pada penyertaan anotasi ke anotasi kerangka kerja yang ada. Untuk menerapkan konvensi yang sama dengan Reflection, para peserta harus menambahkan atau mengubah lebih banyak baris kode. Selain itu, seperti yang disajikan di Bagian 7 , dan menurut pengalaman para peserta, penerapan tugas dengan Reflection API dapat dilakukan dengan menggunakan metode dan cara yang berbeda. Selain itu, hal ini dicampur dengan logika pemrosesan kerangka kerja, yang mengharuskan pengembang untuk memeriksa lebih banyak kode sumber daripada penerapan tugas dengan Esfinge Metadata API.

8.2 Waktu Pelaksanaan
Berdasarkan hasil yang dikumpulkan dari kuesioner, kita dapat melihat bahwa peserta membutuhkan waktu yang hampir sama rata-rata untuk mengimplementasikan tugas dengan kedua pendekatan. Kita dapat melihat pada Gambar 7 bahwa persentil ketiga untuk Esfinge adalah 36,25 menit, hampir sama dengan waktu rata-rata untuk pendekatan Refleksi, yaitu 36 menit. Itu berarti bahwa 75% peserta mengimplementasikan tugas untuk Esfinge Metadata API dengan waktu yang lebih rendah atau sama dengan waktu rata-rata Reflection API. Akibatnya, waktu rata-rata yang diperlukan untuk mengimplementasikan tugas dengan Esfinge Metadata API lebih rendah daripada dengan Reflection API, di mana yang pertama memiliki rata-rata 29 menit dan yang terakhir 36 menit. Nilai tertinggi untuk kedua pendekatan adalah 60 menit. Namun, untuk Esfinge Metadata API, nilai ini dianggap sebagai satu outlier karena hanya satu peserta yang membutuhkan 60 menit untuk mengimplementasikan tugas. Sebaliknya, nilai ini muncul tiga kali untuk reflection API.

Kami mengharapkan waktu implementasi yang jauh lebih singkat untuk Esfinge Metadata API. Karena penerapan konvensi memerlukan lebih sedikit kode untuk ditulis, para peserta dapat menerapkan solusi tersebut jauh lebih cepat. Akan tetapi, hasil kami menunjukkan bahwa para peserta menghabiskan lebih sedikit waktu untuk menerapkan solusi tersebut tetapi tetap perlu membaca dokumentasi. Sebaliknya, saat menggunakan Reflection API, para peserta memerlukan lebih banyak waktu untuk menavigasi kerangka kerja dan memahami di mana metadata harus diproses untuk menerapkan konvensi. Kesulitan dalam memahami dan menggunakan dokumentasi pada Esfinge Metadata API dan menavigasi kode saat menerapkan dengan Reflection membuat waktu implementasi menjadi sangat mirip. Dengan lebih banyak pelatihan dan pengalaman dengan kerangka kerja tersebut, waktu implementasi dengan Esfinge Metadata API akan cenderung sesuai dengan ekspektasi awal kami.

Dengan menganalisis data yang dikumpulkan dari Gambar 8 , kita dapat melihat bahwa memahami dokumentasi mempengaruhi waktu implementasi peserta karena delapan peserta menyatakan bahwa itu sulit. Kerugian kurva pembelajaran, yang disajikan dalam kesulitan Gambar 9 , melengkapi argumen ini karena 10 peserta menyatakan bahwa kurva pembelajaran yang besar merupakan kerugian untuk Esfinge Metadata API. Hasil mengenai kurva pembelajaran ini konsisten dengan studi lain yang membandingkan solusi berdasarkan metadata [ 55 ] dengan yang lain. Menguatkan ini, studi lain menunjukkan bahwa sulit untuk men-debug kode dengan anotasi karena ketidakterusterangannya [ 54 ], yang mengungkapkan bahwa menambahkan perilaku melalui konfigurasi anotasi mungkin tidak intuitif pada awalnya. Namun, kesulitan awal ini dapat dikurangi setelah pengembang lebih terbiasa dengan API, seperti yang ditunjukkan dalam eksperimen yang lebih lama ini, di mana struktur kode lebih konsisten di seluruh rangkaian tugas saat menggunakan API berbasis metadata [ 19 ].

Kami juga menganggap hasil ini positif karena memahami mekanisme konvensi kode Esfinge Metadata API adalah tugas satu kali saja. Setelah mempelajari pendekatan ini, pengguna tidak akan menghabiskan banyak waktu untuk membaca dokumentasinya. Namun, untuk Reflection API, kerugian seperti kode yang rumit (delapan), kode terduplikasi (delapan), dan sulit dipelihara (tujuh), seperti yang disajikan dalam Gambar 9 , tidak bergantung pada pembelajaran pendekatan Reflection dan bergantung pada aplikasi yang diimplementasikan. Aspek lain yang mendukung penegasan ini adalah bahwa untuk Reflection API, peserta menyatakan kesulitan yang terkait dengan kode sumber dan implementasi tugas. Menurut Gambar 8 , jawaban yang paling sering adalah menavigasi kode sumber, menemukan di mana konvensi harus diimplementasikan, dan mengimplementasikan fitur, serta menggunakan Reflection API. Kesulitan yang ditetapkan ini juga dapat membenarkan bahwa waktu yang diperlukan untuk mengimplementasikan konvensi kode menggunakan Reflection API akan bergantung pada navigasi kode.

8.3 Kompleksitas Kode
Respons peserta konsisten dengan kode yang mereka hasilkan. Kita dapat melihat pada Tabel 8 bahwa konvensi kode Reflection API memiliki lebih banyak baris kode. Selain itu, peserta yang menerapkan konvensi kode dengan beberapa baris kode, seperti peserta P5, menghasilkan baris kode yang jauh lebih kompleks daripada Esfinge Metadata API. Karena Esfinge Metadata API hanya mengandalkan penyisipan anotasi kode ke anotasi kerangka kerja, saat satu baris kode ditambahkan ke implementasi Esfinge Metadata, satu-satunya elemen kode yang ditambahkan adalah anotasi kode. Namun, peserta P5 menggunakan 12 pemanggilan metode, satu atribusi, dan satu kondisional untuk Reflection API. Kita juga dapat melihat bahwa peserta P10 menerapkan konvensi kode Esfinge Metadata API menggunakan empat baris dan tiga dengan pendekatan Reflection. Namun, peserta P10 membuat tiga pemanggilan metode: satu kondisional atau loop dan dua atribusi.

Seperti yang diharapkan, Esfinge Metadata API menghasilkan kode yang jauh lebih sederhana. Kompleksitas tambahan ini terjadi karena pendekatan Esfinge Metadata API mengonfigurasi konvensi kode dalam anotasi kerangka kerja. Namun, saat menggunakan Reflection API, logika diimplementasikan secara bercampur dengan kode pembacaan metadata. Peserta juga telah mengimplementasikan kode yang sangat mirip untuk konvensi yang berbeda, menambahkan beberapa redundansi ke kode sumber. Kami percaya kompleksitas ini akan tumbuh lebih banyak jika lebih banyak konvensi ditambahkan karena memprosesnya dengan refleksi memerlukan lebih banyak baris kode untuk ditulis, dan dalam beberapa kasus, metode yang kompleks harus diimplementasikan. Hasil ini memperkuat salah satu temuan Guerra et al. [ 19 ], di mana penulis juga menemukan bahwa kerangka kerja yang diimplementasikan dengan Esfinge Metadata API menghasilkan kode yang kurang kompleks. Selain itu, kita dapat menemukan bukti tentang kompleksitas kode saat mengamati Listing 15, yang menyajikan solusi konvensi untuk anotasi kerangka kerja @IsParameterPresent menggunakan Reflection API. Solusi ini diimplementasikan oleh peserta P1 dan Listing 16, di mana solusi untuk konvensi yang sama diimplementasikan menggunakan Esfinge Metadata API.

8.4 Ancaman terhadap Validitas
8.4.1 Ancaman Kebenaran
Kami mengevaluasi respons dan kode sumber yang dihasilkan secara kualitatif. Kami harus memeriksa kode sumber secara manual, yang berarti pengetahuan kami tentang mengevaluasi Refleksi dan Metadata mungkin telah memengaruhi kesimpulan kami. Untuk mengurangi beberapa kesalahan ini, kami menggunakan alat pembanding kode sumber untuk memverifikasi perbedaan antara kode sumber asli dan kode yang diberikan oleh siswa.

8.4.2 Ancaman Eksekusi
Paruh pertama percobaan ini dilakukan di kelas, dan para siswa dapat menyelesaikannya dari jarak jauh di lingkungan mereka. Mereka bertanggung jawab untuk mengukur waktu pelaksanaan mereka sendiri. Beberapa peserta mungkin memiliki lingkungan yang lebih baik, dengan lebih sedikit gangguan, dan dapat lebih fokus pada pelaksanaan. Selain itu, fakta bahwa para peserta mengukur waktu sendiri dapat menimbulkan beberapa kesalahan.

8.4.3 Contoh Ancaman
Ancaman lain terhadap validasi kami adalah kami hanya memiliki mahasiswa sarjana, yang berarti beberapa mungkin tidak memiliki pengalaman dalam mengimplementasikan atau mengembangkan kerangka kerja berbasis metadata. Untuk mengurangi ancaman ini, kami mencoba menyediakan dokumentasi tentang Esfinge Metadata API dan pelajaran tentang Reflection API. Kami juga menyediakan langkah-langkah yang harus mereka ikuti dalam eksperimen ini untuk memastikan bahwa para peserta menjalankan tugas dalam urutan yang ditentukan dan mengikuti panduan yang sama untuk menyimpulkan eksperimen. Ukuran sampel juga dapat memengaruhi kesimpulan kami dan generalisasi hasil. Karena kami memiliki sejumlah kecil peserta, kami tidak dapat menggeneralisasi hasil kami untuk populasi yang besar. Namun, dengan sampel kecil ini, kami berhasil mendapatkan kesan pertama tentang potensi solusi ini. Dalam studi kasus ini, pendekatan baru tersebut meningkatkan waktu pengembangan dan menghasilkan kode yang lebih mudah dipelihara dan dibaca. Untuk menggeneralisasi hasil ini, kami perlu mereproduksi eksperimen ini dengan sampel mahasiswa yang lebih besar. Penting untuk menyoroti bahwa studi pertama ini difokuskan pada evaluasi bagaimana pendekatan baru ini dapat digunakan untuk implementasi konvensi atas konfigurasi, dan kami yakin bahwa studi pertama ini menghasilkan hasil yang menarik.

8.4.4 Ancaman Pengetahuan
Peserta mengikuti pelatihan untuk kedua pendekatan tersebut. Akan tetapi, mereka mengikuti pelatihan yang berbeda untuk setiap pendekatan. Peserta mengikuti beberapa kelas (tatap muka) tentang Java Reflection API. Untuk Esfinge Metadata API, mereka memiliki akses ke dokumentasi yang disediakan, dan itu adalah interaksi pertama mereka dengan framework tersebut. Selain itu, Reflection API memiliki banyak dokumentasi, seperti tutorial, Javadoc, dan sumber media lainnya. Peserta hanya memiliki dokumentasi yang disediakan untuk framework Esfinge, dan tutorial tentang framework tersebut lebih jarang jika dibandingkan dengan Reflection API. Hal lain tentang dokumentasi adalah bahwa para peneliti menyiapkan dokumentasi tersebut, yang berarti bahwa pengetahuan kami sebelumnya tentang framework tersebut membuat kami melewatkan beberapa aspek penting saat membuat dokumentasi.

8.5 Implikasi dan Dampak
Pendekatan yang diusulkan berdampak pada pengembang dan peneliti. Pertama, pengembang dapat menggunakan pendekatan ini untuk menentukan konvensi mereka. Menerapkan konvensi atas konfigurasi menggunakan pendekatan kami menghasilkan hasil yang menarik karena peserta studi dengan cepat menerapkan konvensi untuk anotasi target. Selain itu, pengembang dapat menerapkan lebih banyak konvensi untuk kerangka kerja mereka karena menerapkan konvensi baru mudah dilakukan menggunakan pendekatan baru ini. Pendekatan ini dapat secara signifikan mengurangi konfigurasi yang diperlukan dalam kerangka kerja berbasis metadata. Dengan konfigurasi yang lebih sedikit, pengembang dapat melakukan lebih sedikit kesalahan saat mengonfigurasi anotasi atau bahkan lupa mengonfigurasi anotasi target jika konvensi diterapkan. Akhirnya, kami mengidentifikasi bahwa komunitas pengembangan terbagi tentang penggunaan anotasi, yang berarti bahwa pendekatan ini dapat cocok untuk pengembang yang tidak menyukai penggunaan anotasi dan dapat menerapkan kerangka kerja mereka menggunakan konvensi alih-alih anotasi.

Pengguna kerangka kerja dapat memperoleh manfaat dari fitur ini dengan membuat konvensi mereka dalam berkas eksternal. Saat ini, pengguna tidak dapat mengonfigurasi konvensi metadata mereka. Karena pengembang kerangka kerja dapat menerapkan lebih banyak konvensi, kerangka kerja berbasis metadata dapat menyediakan lebih banyak konvensi kepada pengguna akhir mereka. Dengan lebih banyak konvensi, pengguna kerangka kerja dapat memiliki pengalaman pengembangan yang lebih baik karena mereka akan menghabiskan lebih sedikit waktu untuk mengonfigurasi metadata dengan mengadopsi konvensi; hal ini akan memungkinkan pengguna kerangka kerja untuk lebih fokus pada logika kerangka kerja mereka daripada pada konfigurasi metadata.

Karena pengguna kerangka kerja tidak dapat menentukan konvensi mereka dari berkas eksternal, ada peluang untuk penelitian dalam aspek ini. Pendekatan kami tidak memungkinkan pengguna untuk menerapkan konvensi mereka dalam berkas eksternal. Di masa mendatang, kami berencana untuk memperluas model kami, termasuk fitur ini. Aspek lainnya adalah bahwa konvensi atas konfigurasi kurang dieksplorasi dalam literatur akademis. Dalam kasus ini, akan lebih tepat untuk menyelidiki keadaan praktik dan mengevaluasi pendekatan saat ini yang menerapkan konvensi atas konfigurasi. Studi semacam itu dapat meningkatkan pengetahuan pengembang saat merancang kerangka kerja berbasis metadata.

Karakteristik lain dari konvensi atas penggunaan konfigurasi adalah bahwa konvensi biasanya tidak terlihat oleh pengembang. Meskipun pendekatan ini mengurangi jumlah konfigurasi, terkadang pengembang tidak mengetahui apa yang sedang diproses di latar belakang. Menggunakan penambahan kode untuk menunjukkan kepada pengembang saat anotasi target ditambahkan berdasarkan konvensi. Dengan cara ini, anotasi kerangka kerja tidak ditampilkan dalam kode sumber, tetapi pengembang masih dapat melihat bahwa konvensi menggantikannya. Dengan pendekatan ini, kami memahami bahwa konfigurasi yang dibuat oleh konvensi lebih transparan bagi pengembang, mengurangi waktu yang dihabiskan untuk mencoba memahami konfigurasi mana yang digantikan oleh konvensi dan meningkatkan pemahaman kode. Berdasarkan kesulitan dalam menggunakan konvensi yang dilaporkan oleh praktisi, pendekatan visualisasi dapat dirancang sebagai tujuan tugas ini. Pendekatan visualisasi ini harus membantu pengembang menentukan bagaimana konvensi memengaruhi elemen target secara visual dan elemen kode mana yang terpengaruh oleh konvensi. Berdasarkan pendekatan visualisasi perangkat lunak, kami dapat, misalnya, mengimplementasikan prototipe alat yang terintegrasi dengan IDE yang ada.

9. Kesimpulan
Dalam makalah ini, kami mengusulkan model yang memungkinkan pengembang untuk mendefinisikan konvensi kode secara terpisah dari kode yang membaca anotasi kode. Model kami memungkinkan definisi deklaratif konvensi atas konfigurasi, yang dapat dikonfigurasi secara terpisah dari kode yang membaca metadata. Untuk menggunakan model ini, pengembang harus menambahkan anotasi konvensi pada deklarasi anotasi kerangka kerja untuk mengonfigurasi konvensi. Kami menerapkan pendekatan ini ke Esfinge Metadata API. Sebagai kasus penggunaan pertama, kami menambahkan konvensi atas konfigurasi ke Esfinge Comparison API untuk mengukur upaya yang diperlukan untuk menerapkan pendekatan ini ke aplikasi yang sudah ada. Hasil dari studi ini sangat memotivasi karena kami dapat mengonfigurasi anotasi konvensi ke anotasi kerangka kerja, mengganti penggunaannya hanya dengan beberapa baris kode.

Kami melakukan studi eksperimental dengan 28 mahasiswa sarjana untuk mengevaluasi model yang kami usulkan. Para mahasiswa harus menerapkan dua konvensi kode dengan pendekatan kami dan dua konvensi lainnya dengan Reflection API. Para mahasiswa mengukur waktu yang diperlukan untuk menerapkan konvensi kode dengan kedua pendekatan tersebut. Setelah menerapkan konvensi, para peserta menjawab kuesioner. Kami menggunakan data yang dikumpulkan dari jawaban kuesioner untuk mengevaluasi bagaimana pendekatan baru ini dapat mendukung pengembangan konvensi kode untuk kerangka kerja berbasis metadata. Analisis kami menunjukkan bahwa pendekatan yang diusulkan menghasilkan kode yang lebih mudah dibaca dan dirawat. Namun, para peserta awalnya mengalami kesulitan dengan menyatakan bahwa pendekatan ini memerlukan kurva pembelajaran yang signifikan. Total waktu yang diperlukan bagi para mahasiswa untuk menerapkan konvensi serupa untuk kedua pendekatan tersebut, tetapi mereka memiliki kesulitan yang berbeda. Sementara mereka perlu menghabiskan waktu untuk membaca dan mempelajari tentang Esfinge API untuk pendekatan Reflection, para peserta harus menavigasi kode sumber kerangka kerja subjek untuk lebih banyak waktu.

Pendekatan yang diusulkan dapat memengaruhi pengembang, pengguna, dan peneliti kerangka kerja. Pertama, pengembang yang menggunakan pendekatan ini dapat menerapkan lebih banyak konvensi untuk kerangka kerja mereka. Model yang kami usulkan memungkinkan perluasan konvensi yang ada dengan mudah, dan menambahkannya ke kerangka kerja dapat dilakukan dengan beberapa baris kode, seperti yang disajikan di Bagian 5 saat kami melakukan studi kasus dan dengan waktu yang dibutuhkan peserta untuk menerapkan konvensi menggunakan pendekatan kami. Meskipun waktu yang dihabiskan sangat mirip, umpan balik siswa menunjukkan bukti bahwa lebih banyak waktu dihabiskan untuk membaca dokumentasi daripada menerapkan fitur. Pengguna kerangka kerja mungkin mendapat manfaat dari kerangka kerja dengan lebih banyak konvensi. Mengingat bahwa kerangka kerja memiliki lebih banyak konvensi, pengguna dapat meningkatkan waktu pengembangan mereka. Pengguna kerangka kerja dapat menghabiskan lebih banyak waktu untuk berfokus pada logika aplikasi mereka daripada mengonfigurasi metadata mereka jika kerangka kerja menerapkan lebih banyak konvensi. Akhirnya, karya ini menghadirkan tantangan bagi para peneliti. Pertama, studi tentang konvensi atas konfigurasi dapat ditingkatkan, yang, hingga saat ini, belum banyak dieksplorasi dalam literatur akademis. Pendekatan baru ini dapat diperluas, yang memungkinkan konvensi didefinisikan dalam file eksternal. Praktisi melaporkan bahwa konvensi sering disembunyikan dalam kode sumber, yang berarti bahwa alat visualisasi dapat membantu pengembang memahami konvensi mana yang mengonfigurasi metadata mereka.

Sebagai perluasan dari pekerjaan ini, kami bermaksud untuk mengimplementasikan fitur-fitur baru ke Esfinge Metadata API untuk mendukung definisi konvensi kode dalam berkas eksternal. Fitur tersebut akan memungkinkan aplikasi untuk memperluas konvensi kerangka kerja, yang memungkinkan pengenalan konvensi khusus aplikasi. Pekerjaan di masa mendatang mungkin juga memperluas dukungan ini untuk membuat konvensi kode yang dipisahkan ke kerangka kerja yang ada. Itu dapat dilakukan dengan menambahkan anotasi kerangka kerja dalam bytecode kelas pada waktu kompilasi berdasarkan konvensi yang ditetapkan dalam berkas konfigurasi. Studi masa depan lainnya dapat menyelidiki dampak penggantian anotasi dengan konvensi dalam aplikasi yang ada, memverifikasi potensinya untuk mengurangi jumlah anotasi dengan menghapus pengulangan anotasi. Terakhir, mengimplementasikan alat visualisasi untuk mendukung pengembang dalam memahami kerangka kerja baru yang mengimplementasikan konvensi atas konfigurasi.