View of Desain Aplikasi Daily Reminder Menggunakan Model-View Controller Dan Data Access Object

(1)

421

Desain Aplikasi Daily Remainder Menggunakan Model-View Controller Dan Data Access Object

Daily Remainder Application Design Using Model-View Controller and Data Access Object

Mohammad Fajar¹, Fudianto Ciuandi², Abdul Munir³

1,2,3Teknik Informatika, STMIK KHARISMA Makassar

E-mail: ¹[email protected], ²[email protected],

Aktivitas dan mobilitas masyarakat, khususnya di perkotaan yang cukup padat dan tinggi memerlukan manajemen waktu secara baik. Di sisi lain, pemakaian smart phone telah menjadi kebutuhan sehari-hari untuk membantu beragam kegiatan penggunanya. Untuk keperluan ini aplikasi pengingat jadwal harian (daily reminder) dapat menjadi aplikasi yang sangat membantu mengelola aktivitas ataupun jadwal kegiatan pengguna smart phone.

Meskipun demikian, aspek kualitas aplikasi atau perangkat lunak, seperti kemudahan modifikasi menjadi faktor penting yang perlu diperhatikan oleh pengembang. Olehnya itu, penelitian ini bertujuan untuk memanfaatkan pendekatan pola Model View Controller (MVC) dan Data Access Object (DAO) dalam merancang aplikasi daily reminder berbasis platform Android. Penggunaan MVC dan DAO didasarkan pada usaha untuk memudahkan perangkat lunak dimodifikasi dimasa depan guna keperluan pengembangan atau perawatan. Pengumpulan data dalam penelitian ini dilakukan melalui studi literatur dan evaluasi rancangan sistem menggunakan metrik berorientasi objek. Berdasarkan hasil pengukuran disimpulkan bahwa pemakaian pendekatan MVC dan DAO dalam desain aplikasi daily reminder menaikkan tingkat modifikasi pada Attribute Hiding Factor (AHF) sebesar 0,042073055, Polymorphism Factor (POF) sebesar 0,164408867 Number of Methods Inherited (NMO) sebesar 20, dan Reuse Ratio (RR) sistem sebesar 0,105263158.

Hal ini menunjukkan pemakaian pola MVC dan DAO tersebut dapat memudahkan aplikasi yang dirancang untuk dimodifikasi di masa depan.

Kata kunci: MVC, DAO, Daily Reminder, Metrik Berorientasi Objek

Abstract

People’s activities that are quite high, especially in urban areas, require good schedule management. On the other hand, the use of smartphone devices today has become a daily necessity that helps users' activities. For this purpose, a daily reminder application can be a very useful application for smartphone users to manage their activities or schedule.

However, the quality of the application or software, such as the ease of modification, is an important factor in which developer should pay attention to how it’s designed. Therefore, the aim of this study is to apply the Model View Controller (MVC) and the Data Access Object (DAO) patterns in designing an Android-based daily reminder application. The use of MVC and DAO design patterns is based on efforts to make the daily reminder application to be simply modified in the future. Data collection in this study was performed through literature studies and evaluation of system design using object-oriented metrics. Evaluation results show that the approaches used in designing the daily reminder application increased the level of modification on the Attribute Hiding Factor (AHF) is 0.042073055, the Polymorphism Factor (POF) is 0.164408867, the Number of Inherited Methods (NMO) is 20, and the system's Reuse Ratio (RR) is 0.105263158. The measurement shows that the MVC and DAO design patterns are able to simplify the designed application for modification in the future.

Keywords: MVC, DAO, Daily Reminder, Object Oriented Metrics

(2)

422

1. PENDAHULUAN

Aktivitas dan mobilitas masyarakat, khususnya di perkotaan yang cukup padat dan tinggi memerlukan manajemen waktu secara baik oleh masing-masing individu. Di sisi lain, pemakaian smart phone juga telah menjadi kebutuhan sehari-hari yang tidak terelakkan lagi. Berkembangnya beragam aplikasi atau perangkat lunak, menjadikan pemakaian smart phone saat ini tidak hanya terbatas untuk kebutuhan berkomunikasi, melainkan juga sebagai alat bantu aktivitas-aktivitas lain seperti buku catatan digital, pengolah kata dan data, hingga sebagai alat pemutar musik dan bermain game. Untuk keperluan manajemen waktu secara baik, maka aplikasi khusus pengingat harian (daily reminder) dapat menjadi aplikasi yang sangat membantu mengelola aktivitas ataupun jadwal kegiatan para pengguna smart phone. Meskipun demikian, pengembangan aplikasi daily reminder tersebut perlu memperhatikan aspek kualitas dari perangkat lunak, seperti kemudahan pemeliharaan dan pengembangannya di masa yang akan datang. Biaya-biaya yang timbul dari proses pemeliharaan perangkat lunak ini bahkan dipandang sebagai biaya yang terbesar dari keseluruhan pengembangan perangkat lunak tersebut [1]⁠. Tingkat pemeliharaan yang baik ditandai dengan kemudahan untuk memodifikasi sistem atau perangkat lunak apabila terjadi perubahan fungsional atau fitur, baik itu penambahan maupun pengurangan fungsionalnya. Untuk kebutuhan ini, salah satu solusi yang banyak digunakan para pengembang perangkat lunak yaitu pemakaian pola desain Model-View Controller (MVC), dimana salah satu kelebihan perancangan sistem menggunakan MVC yaitu tingkat maintainability-nya [2]. ⁠Seperti perancangan perangkat lunak persediaan berbasis web pada toko matahari motor Pontianak yang menggunakan framework MVC codeigniter [3]⁠. Begitu pula studi yang memanfaatkan MVC dalam rancang bangung website SMK Yayasan Bakti Prabumulih [4]⁠.⁠ Meskipun demikian, studi-studi yang dilakukan tersebut, belum membahas bagaimana abstraksi antarmuka MVC untuk keperluan interaksi dengan sistem basis data, hal ini dikarenakan pola desain MVC memang belum mewajibkan adanya sebuah abstraksi antarmuka (interface) yang berisi metode-metode yang mewakili operasi yang dapat dilakukan pada basis data. Sementara abstraksi interface ini akan memudahkan dalam proses perpindahan sistem ke berbagai jenis basis data. Oleh karena itu, penelitian ini bertujuan untuk mengimplementasikan pendekatan pola desain MVC dan Data Access Object (DAO) dalam perancangan perangkat lunak pengingat harian (Daily reminder) untuk meningkatkan kemudahan perawatan kode aplikasi. Pola desain DAO menyediakan interface akses data ke komponen bisnis dan presentasi, memberikan kemandirian sumber data dan antarmuka pemrograman aplikasi atau Application Programming Interface (API) persistensi penyimpanan yang digunakan, serta berkontribusi pada portabilitas komponen sistem dan memfasilitasi migrasi ke data yang berbeda sumber [5]⁠.

2. METODE PENELITIAN

Penelitian dilakukan dengan mengikuti skenario utama pengembangan perangkat lunak sebagai berikut:

1. Analisis kebutuhan aplikasi daily reminder, dimana spesifikasi kebutuhan sistem didapatkan dari studi pustaka terkait pengembangan aplikasi Reminder Pada Android Mobile Device [6]⁠ serta Desain dan implementasi Sistem Penjadwalan Agenda Berbasis Android [7]⁠. Visualisasi proses analisis disajikan dalam UML diagram use-case dan diagram activity.

2. Selanjutnya pada tahapan desain, dirancang arsitektur sistem, antarmuka (UI) pengguna sistem dan struktur sistem menggunakan diagram class.

3. Implementasi rancangan ke dalam platform Android menggunakan bahasa pemrograman Java

(3)

423

4. Evaluasi sistem menggunakan metrik berorientasi objek. Evaluasi perangkat lunak dapat dilakukan dengan beragam cara dan teknik yang telah banyak dikaji, meskipun demikian teknik yang digunakan perlu mempertimbangkan tujuan yang ingin dicapai.

Sebagai contoh jika diinginkan untuk mengetahui struktur rancangan maka parameter seperti kopling dan kohesi perlu diamati [8] [9]. Olehnya itu, pada studi ini untuk melihat apakah sistem yang dirancang menggunakan MVC dan DAO dapat menaikkan tingkat modifikasi, maka pengukuran tingkat modifikasi sistem perlu dilakukan dengan mengukur aspek enkapsulasi, polimorfisme, dan reusability. Dalam studi [10]⁠ dan [11]⁠

dijelaskan bahwa enkapsulasi dapat diukur menggunakan parameter Attribute Hiding Factor (AHF) dan Method Hiding Factor (MHF), polimorfisme dapat diukur menggunakan Polymorphism Factor (POF) dan Number of Methods Inherited (NMO), serta reusability diukur menggunakan Reuse Ratio (RR) dan Specialization ratio (SR). Pengukuran MHF merujuk pada persamaan (1) dan (2) berikut:

𝑀𝐻𝐹 = ∑^𝑇𝐶_𝑖 ∑^𝑀_𝑚=1^𝑑^(𝐶^𝑖⁾(1 − 𝑉(𝑀_𝑚𝑖))

∑^𝑇𝐶_𝑖=1𝑀_𝑑(𝐶_𝑖) (1)

𝑉(𝑀𝑚𝑖) = ∑^𝑇𝐶_𝑗=1𝑖𝑠_{𝑣𝑖𝑠𝑖𝑏𝑙𝑒}(𝑀_𝑚𝑖, 𝐶_𝑗)

𝑇𝐶 − 1 (2)

𝑖𝑠_{𝑣𝑖𝑠𝑖𝑏𝑙𝑒(𝑀}_𝑚𝑖_,𝐶_𝑖)= {1 𝑖𝑓𝑓 𝑗 ≠ 𝑖^𝐶^𝑗 𝑑𝑎𝑛 𝐶_𝑗 𝑏𝑖𝑠𝑎 𝑚𝑒𝑚𝑎𝑛𝑔𝑔𝑖𝑙 𝑀_𝑚𝑖 0 𝑠𝑒𝑏𝑎𝑙𝑖𝑘𝑛𝑦𝑎

Dimana Md(Ci) adalah jumlah metode yang dideklarasikan pada kelas ke-i dari sistem, i adalah iterator untuk perhitungan dari kelas ke-1 sampai kelas ke- TC dari sistem jika sistem memiliki TC kelas. m adalah iterator untuk perhitungan dari metode ke-1 dari kelas ke i dari sistem sampai metode ke Md(Ci) dari kelas ke i jika kelas ke i memiliki Md(Ci) metode yang terdefinisikan dalam kelas tersebut. Dan V(Mmi) dapat merupakan jumlah kelas yang dapat memanggil metode ke-m dari kelas ke-i selain kelas i itu sendiri dibagi total kelas sistem yang telah dikurangi dengan 1. Untuk mengukur AHF dapat dilakukan dengan persamaan (3) dan (4), berikut:

𝐴𝐻𝐹 = ^∑ ^∑ ^{(1−𝑉(𝐴}^𝑚𝑖⁾⁾

𝐴𝑑 (𝐶𝑖) 𝑚=1 𝑇𝐶𝑖

∑^𝑇𝐶_𝑖=1𝐴_𝑑 (𝐶_𝑖) (3) 𝑉(𝐴_𝑚𝑖) = ∑^𝑇𝐶_𝑗=1𝑖𝑠_{𝑣𝑖𝑠𝑖𝑏𝑙𝑒}(𝐴_𝑚𝑖, 𝐶_𝑖)

𝑇𝐶 − 1 (4)

Dimana Ad(Ci) adalah jumlah atribut yang dideklarasikan pada kelas ke-i dari sistem, i adalah iterator untuk perhitungan dari kelas ke-1 sampai kelas ke- TC dari sistem jika sistem memiliki TC kelas. m adalah iterator untuk perhitungan dari atribut ke-1 dari kelas ke i dari sistem sampai atribut ke Md(Ci) dari kelas ke i jika kelas ke i memiliki Ad(Ci) atribut yang terdefinisikan dalam kelas tersebut. Dan V(Ami) dapat merupakan jumlah kelas yang dapat memanggil atribut ke-m dari kelas ke-i selain kelas i itu sendiri dibagi total kelas pada sistem yang telah dikurangi dengan 1. untuk POF dapat dihitung berdasarkan persamaan (5) berikut:

𝑃𝑂𝐹 = ^∑^𝑇𝐶^𝑖=1^𝑀^𝑂^(𝐶^𝑖⁾

∑^𝑇𝐶_𝑖=1[𝑀_𝑛(𝐶_𝐼) × 𝐷𝐶(𝐶_𝑖)] (5)

Dimana Mo(Ci) merupakan jumlah metode yang merupakan hasil override pada kelas ke i,

(4)

424

Mn(Ci) merupakan jumlah metode pada kelas ke i yang merupakan metode baru dan bukan metode hasil override, i merupakan iterator untuk perhitungan dari kelas ke-1 sampai kelas ke-TC apabila TC merupakan jumlah kelas dalam sistem, DC(Ci) merupakan jumlah turunan dari kelas ke i. Untuk NMO dihitung berdasarkan formula (6) berikut:

𝑁𝑀𝑂 = ∑ 𝑚𝑜_𝐼

𝑇𝐶

𝑖=1

(6)

Dimana moi merupakan jumlah metode dari kelas ke-i jika metode tersebut di override oleh kelas lain, i merupakan iterator untuk perhitungan dari kelas ke-1 sampai kelas ke-TC apabila TC merupakan jumlah semua kelas pada sistem. Selanjutnya untuk mengukur parameter RR dan SR dapat menggunakan formula (7) dan (8) berikut:

𝑅𝑅 = 𝑆𝐶

𝑇𝐶 (7)

𝑆𝑅 = 𝐼𝐶

𝑆𝐶 (8)

Dalam penelitian ini, pengukuran tingkat modifikasi sistem dilakukan dalam dua kondisi, yaitu kondisi sebelum aplikasi daily reminder menggunakan pola MVC-DAO dan kondisi pengukuran setelah aplikasi dirancang menggunakan MVC-DAO. Setelah diperoleh data hasil pengukuran, selanjutnya keduanya dibandingkan untuk menentukan apakah sistem yang menggunakan MVC-DAO berdampak pada kenaikan tingkat modifikasi atau tidak. Hasil evaluasi dan pengukuran ini dijadikan sebagai dasar kesimpulan akhir.

3. HASIL DAN PEMBAHASAN 3.1. Analisis Sistem

Berdasarkan kebutuhan, aplikasi pengingat harian terdiri dari beberapa fitur utama seperti: menambah target mingguan, menempatkan target mingguan ke jadwal harian, dan lihat notifikasi jadwal harian. Selain itu, fitur pencarian jadwal dan target mingguan serta laporan juga melengkapi spesifikasi fungsional aplikasi. Spesifikasi kebutuhan sistem aplikasi pengingat harian secara lengkap disajikan dalam diagram use case seperti pada Gambar 1.

(5)

425

Gambar 1. Diagram Use Case Aplikasi Daily Reminder

Selanjutnya, untuk memahami skenario secara detail, setiap use case dijabarkan kedalam diagram aktivitas yang menggambarkan kegiatan atau aksi yang ada pada use case tersebut. Sebagai contoh Gambar 2 menyajikan salah satu diagram aktivitas untuk melihat target mingguan. Aktivitas dipicu oleh User dengan membuka aplikasi, selanjutnya sistem akan menampilkan menu utama, yang dilanjutkan dengan user memilih menu target mingguan yang akan diperiksa oleh sistem ke basis data dan hasilnya ditampilkan kepada user.

(6)

426

Gambar 2. Diagram Lihat Target Mingguan

3.2. Desain Sistem

Setelah analisis kebutuhan dan aktivitas pada use case telah dipahami, selanjutnya pada tahapan desain, perlu dirancang arsitektur sistem, antarmuka pengguna aplikasi dan struktur statik dari aplikasi pengingat harian.

(7)

427 3.2.1. Desain Arsitektur Sistem

Pada desain arsitektur ini, pengguna berinteraksi dengan komponen view, kemudian view akan mengirimkan jenis interaksi yang dilakukan oleh pengguna terhadap aplikasi. Controller akan menjalankan proses sesuai interaksi yang terjadi kemudian mengirimkan respon ke komponen view. Komponen view akan menyampaikan respon yang akan dilihat langsung oleh pengguna. Apabila interaksi yang dilakukan oleh pengguna membutuhkan proses pengelolaan data, maka controller meminta model untuk menjalankan proses tersebut yang nantinya jika hal tersebut berkaitan dengan basis data, maka akan dihubungkan dengan objek DAO. Selanjutnya objek DAO menjalankan proses query sesuai permintaan dari model yang kemudian hasilnya akan dikirim ke model untuk diteruskan ke controller sebagai umpan balik ke pengguna melalui view. Gambar 3 memperlihatkan rancangan arsitektur sistem aplikasi daily reminder pada studi ini.

Gambar 3. Arsitektur Sistem

3.2.2. Desain Antarmuka Pengguna

Target platform aplikasi daily reminder yaitu lingkungan berbasis Android, Gambar 4 (a) memperlihatkan menu utama aplikasi dimana pengguna dapat memilih apakah ingin mengelola data target mingguan (Weekly Goals) atau harian (Daily Schedule).

(8)

428

(a) Menu Utama (b) Fitur menambah data jadwal harian Gambar 4. Rancangan Antarmuka Pengguna Aplikasi Daily Remainder

Sementara Gambar 4(b) merupakan tampilan penambahan data jadwal harian, dimana pengguna dapat mengisi data waktu, tempat, aktivitas, dan jenis pengingat yang akan dipilih. Setelah itu, pengguna dapat mengetuk tombol tambah untuk menambah jadwal harian tersebut ke sistem.

3.2.3. Desain Struktur Class Aplikasi

Desain struktur class aplikasi daily reminder terdiri dari sejumlah class dan antarmuka (interface) baik itu yang yang didefinisikan sendiri maupun class dan interface bawaan yang tersedia pada pustaka atau platform untuk kebutuhan pola desain MVC dan DAO. Seperti class Fragment yang merupakan induk dari BaseController, class BaseView merupakan induk dari class RolesAndGoalsListView, dan class BaseModel yang merupakan induk dari class RolesAndGoalsListModel. Sementara interface RolesAndGoalsDAO diimplementasikan oleh class RolesAndGoalsDAO_impl. Gambar 5 memperlihatkan desain struktur class aplikasi yang dikembangkan.

(9)

429

Gambar 5. Rancangan Diagram Class Daftar Target Harian 3.3. Evaluasi

Untuk mengetahui kualitas rancangan aplikasi daily reminder, khususnya tingkat modifikasinya. Digunakan pengukuran metrik rancangan berorientasi objek (MOOD) yang ditinjau dari aspek tingkat enkapsulasi, polimorfisme, serta reusabilitas aplikasi yang tidak menggunakan model MVC-DAO dan aplikasi yang dirancang menggunakan MVC- DAO. Hasil pengukuran tersebut disajikan pada tabel 1.

Tabel 1. Hasil Pengukuran Metrik Rancangan Berorientasi Objek Metrik Aplikasi Menggunakan

MVC-DAO

Aplikasi Tanpa

MVC-DAO Kenaikan nilai Enkapsulasi MHF 0,267466637 0,297101449 -0,029634812

AHF 0,86746988 0,825396825 0,042073055

Polimorfisme POF 0,767857143 0,603448276 0,164408867

NMO 32 12 20

Reusability RR 0,315789474 0,210526316 0,105263158

SR 1,666666667 2,25 -0,583333333

Berdasarkan tabel 1, terlihat bahwa untuk MHF di tingkat enkapsulasi, aplikasi yang menggunakan model MVC-DAO lebih rendah sebesar 0,029634812 dibandingkan dengan aplikasi tanpa MVC-DAO. Hal ini disebabkan karena pada aplikasi yang dirancang menggunakan MVC-DAO, metode pada class tersebut (khususnya pada class yang bertindak sebagai komponen MVC-DAO), harus dapat diakses oleh class lain agar dapat menjalankan tanggung jawabnya. Sebagai contoh untuk metode insert pada DailyScheduleModel harus dapat diakses oleh AddDailyScheduleController, sebagai reaksi yang diberikan controller apabila terjadi interaksi pada AddDailyScheduleView.

Sebaliknya nilai AHF aplikasi yang menggunakan MVC-DAO lebih tinggi sebesar 0,042073055 dibandingkan dengan aplikasi tanpa MVC-DAO. Hasil ini disebabkan karena perbedaan responsibility pada class-class dari sistem yang menggunakan MVC-DAO yang

(10)

430

tidak mengharuskan atribut dari sebuah komponen untuk diakses oleh komponen lain.

Sebagai contoh pada DailyScheduleModel, atribut DailyScheduleDAO tidak perlu diberikan akses modifier public, karena hanya DailyScheduleModel yang bertanggung jawab untuk meminta DailyScheduleDAO untuk melakukan queri langsung pada SQLite untuk melakukan pengolahan data pada basis data. Untuk nilai POF dan NMO pada aspek polimorfis, menunjukkan aplikasi yang dirancang menggunakan MVC-DAO DAO lebih tinggi dibandingkan aplikasi tanpa pola MVC-DAO. Ini disebabkan adanya komponen AbstractDAO pada pola desain DAO yang diterapkan pada rancangan. Komponen AbstractDAO berupa interface yang wajib diimplementasikan oleh ConcreteDAO dengan hasil implementasi yang disesuaikan dengan teknik pengolahan basis data sesuai dengan data source yang digunakan sistem. Disamping itu class BaseView, BaseController, dan BaseModel pada komponen view, controller, dan model juga memiliki metode abstract yang diimplementasikan komponen MVC lainnya mendukung peningkatan nilai POF dan NMO pada aplikasi yang menggunakan MVC-DAO. Adapun untuk nilai RR pada aplikasi yang dirancang menggunakan MVC-DAO lebih tinggi sebesar 0,105263158 dibandingkan aplikasi tanpa MVC-DAO, hal ini dikarenakan pada pola desain DAO mewajibkan adanya ConcreteDAO yang menjadi turunan AbstractDAO. Di samping itu untuk class BaseView, BaseController, dan BaseModel pada komponen view, controller, dan model juga memiliki banyak turunan. Untuk nilai SR sistem yang belum menerapkan pendekatan MVC DAO lebih tinggi sebesar 0,583333333 dibandingkan dengan sistem yang telah menerapkan pola MVC DAO. Ini disebabkan oleh jumlah class yang menjadi superclass jauh lebih banyak dibandingkan class yang menjadi subclass pada aplikasi yang menggunakan MVC-DAO.

Salah satu faktor yang menyebabkan kondisi tersebut yaitu controller pada pustaka platform sistem android yang apabila ingin mendefinisikan proses yang akan dilakukan ketika terjadi interaksi pada view harus menjadi turunan dari class view listener. Akibatnya, semakin banyak jenis view listener yang digunakan pada sebuah controller, semakin banyak superclass tersebut.

Dari hasil pengukuran tersebut dapat dilihat bahwa desain aplikasi menggunakan pola MVC dan DAO meningkatkan enkapsulasi pada atribut kelas dari sistem yang diukur dengan pengukuran AHF, faktor polimorfisme yang diukur dengan POF, jumlah metode yang didefinisikan ulang oleh subclass dari superclass sebuah kelas pada sistem yang diukur menggunakan NMO, dan rasio penggunaan kembali kelas pada sistem yang diwakili dengan parameter RR.

4. KESIMPULAN DAN SARAN

Berdasarkan hasil evaluasi dan pengukuran metrik berorientasi objek disimpulkan bahwa pemakaian pendekatan MVC dan DAO pada desain aplikasi daily reminder dapat menaikkan tingkat modifikasi parameter AHF sistem sebesar 0,042073055, POF sistem sebesar 0,164408867, NMO sistem sebesar 20, dan parameter RR sistem sebesar 0,105263158. Hal ini menunjukkan pemakaian kedua pendekatan tersebut dapat memudahkan aplikasi yang dirancang untuk dimodifikasi.

DAFTAR PUSTAKA

[1] U. Kaur and G. Singh, “A Review on Software Maintenance Issues and How to Reduce Maintenance Efforts,” Int. J. Comput. Appl., vol. 118, no. 1, pp. 6–11, 2015.

[2] R. N. Thakur and U. S. Pandey, “The Role of Model-View Controller in Object Oriented Software Development,” Nepal J. Multidiscip. Res., vol. 2, no. 2, pp. 1–6, 2019.

(11)

431

[3] Dea Erlinda Thendy Salim and Sandy Kosasi, “Perancangan Perangkat Lunak Persediaan Berbasis Web Pada Toko Matahari Motor Pontianak,” vol. Vol 11. No 2, no. x, pp. 47–58, 2022.

[4] K. Wijaya and A. Christian, “Implementasi Metode Model View Controller (MVC) Dalam Rancang Bangun Website SMK Yayasan Bakti Prabumulih,” Paradig. - J.

Komput. dan Inform., vol. 21, no. 1, pp. 95–102, 2019.

[5] A. L. De Oliveira, A. L. A. Menolli, and R. G. Coelho, “Implementing the data access object pattern using aspectj,” ICEIS 2008 - Proc. 10th Int. Conf. Enterp. Inf. Syst., vol.

DISI, no. October 2015, pp. 523–530, 2008.

[6] D. D. Purwanto, “Aplikasi Reminder Pada Android Mobile Device,” vol. 20, no. 1, pp. 17–23, 2014.

[7] R. Rahmah and M. Mansur, “Desain dan implementasi sistem penjadwalan agenda berbasis android,” Digit. Zo. J. Teknol. Inf. dan Komun., vol. 8, no. 2, pp. 196–206, 2017.

[8] J. Voas and R. Kuhn, “What Happened to Software Metrics?” Computer, vol. 50, no. 5. IEEE Computer Society, pp. 88–98, May 01, 2017. doi: 10.1109/MC.2017.144.

[9] J. Ludwig, S. Xu, and F. Webber, “Static software metrics for reliability and maintainability,”

in Proceedings - International Conference on Software Engineering, IEEE Computer Society, May 2018, pp. 53–54. doi: 10.1145/3194164.3194184.

[10] N. Nwe and E. Thu, “Measuring modifiability in model driven development using object oriented metrics,” Adv. Sci. Technol. Eng. Syst., vol. 3, no. 1, pp. 244–251, 2018.

[11] R. Harrison, S. J. Counsell, and R. V. Nithi, “An evaluation of the MOOD set of object- oriented software metrics,” IEEE Trans. Softw. Eng., vol. 24, no. 6, pp.

491–496, 1998.