PENGEMBANGAN MEKANISME ARSITEKTUR SOFTWARE REUSE
DALAM PENGEMBANGAN APLIKASI WEB
(STUDI KASUS DIREKTORAT SUMBER DAYA MANUSIA IPB)
FRANS RUDOLF BANJARNAHOR
SEKOLAH PASCASARJANA INSTITUT PERTANIAN BOGOR
PERNYATAAN MENGENAI TESIS DAN
SUMBER INFORMASI SERTA PELIMPAHAN HAK CIPTA*
Dengan ini saya menyatakan bahwa tesis berjudul Pengembangan Mekanisme Arsitektur Software Reuse Dalam Pengembangan Aplikasi Web
(Studi Kasus Direktorat Sumber Daya Manusia IPB) adalah benar karya saya dengan arahan dari komisi pembimbing dan belum diajukan dalam bentuk apa pun kepada perguruan tinggi mana pun. Sumber informasi yang berasal atau dikutip dari karya yang diterbitkan maupun tidak diterbitkan dari penulis lain telah disebutkan dalam teks dan dicantumkan dalam Daftar Pustaka di bagian akhir tesis ini.
Dengan ini saya melimpahkan hak cipta dari karya tulis saya kepada Institut Pertanian Bogor.
Bogor, Mei 2015
Frans Rudolf Banjarnahor
RINGKASAN
FRANS RUDOLF BANJARNAHOR. Pengembangan Mekanisme Arsitektur
Software Reuse Dalam Pengembangan Aplikasi Web (Studi kasus Direktorat
Sumber Daya Manusia IPB). Dibimbing oleh YANI NURHADRYANI dan IRMAN HERMADI.
Saat ini praktek pengembangan perangkat lunak semakin mengkhawatirkan. Hal ini disebabkan oleh biaya yang tinggi dan produktivitas yang buruk karena sering kali mengembangkan perangkat lunak secara berulang-ulang. Penerapan
software reuse adalah salah satu solusi untuk permasalahan ini. Software reuse
adalah penggunaan kembali segala hal pada perangkat lunak menggunakan resource
dan domain knowledge sebelumnya yang memiliki nilai reusability atau merancang
suatu perangkat lunak yang baru dengan prinsip reusability. Software reuse
bertujuan meningkatkan kualitas dan produktivitas perangkat lunak dengan teknik dan strategi yang terus dikembangkan. Software reuse merupakan konsep yang
sudah lama digunakan. Konsep software reuse telah digunakan semenjak praktisi
bidang komputer membuat sebuah baris program dan kemudian digunakan kembali baik untuk penambahan fungsi baru, atau sekedar menggunakan pengetahuan sebelumnya untuk mengembangkan yang lain.
Semenjak tahun 2003, IPB dalam Visi dan Misinya mendefinisikan sebuah pilar yang disebut dengan Sentralisasi Administrasi dan Desentralisasi Akademik dan Riset (SADAR). Konsentrasi dari pilar ini adalah melakukan administrasi institusi secara terpusat. Untuk mendukung hal ini, peningkatan dan pengembangan sistem informasi terus dilakukan, terutama pada sistem informasi berbasis web. Peningkatan ini memiliki kendala dalam hal sumber daya, integrasi data dan sistem, serta perubahan proses bisnis yang dapat terjadi sewaktu-waktu.
Penerapan software reuse dalam pengembangan aplikasi berbasis web dengan
studi kasus pada sistem informasi di Direktorat Sumber Daya Manusia merupakan tahapan inisialisasi software reuse yang menghasilkan suatu mekanisme arsitektur
dalam pengembangan aplikasi web. Dalam penelitian ini, metode yang dilakukan yaitu: perancangan mekanisme arsitektur, pemilihan teknologi yang digunakan, implementasi aset reuse dan pengujian aset dengan membuat aplikasi web. Metode
implementasi aset reuse menghasilkan aset akses ke basis data berdasarkan analisis
pada domain permasalahan dan aset presentasi (antarmuka). Tahapan selanjutnya adalah melakukan pengujian terhadap aset tersebut dengan membuat proyek aplikasi web dalam suatu mekanisme distribusi dan penggunaan aset melalui server
repository. Aplikasi web tersebut merupakan perangkat lunak sistem informasi
berbasis web yang berada di bawah pengelolaan Direktorat Sumber Daya Manusia yaitu Sistem Informasi Manajemen Kepegawai (SIMPEG) dan sistem informasi yang berkaitan dengan SIMPEG yaitu aplikasi Sistem Manajemen Agenda Pimpinan (SMAP). Pengembangan mekanisme arsitektur software reuse pada
penelitian ini diharapkan dapat meminimalisir kendala pengembangan web yang terjadi di IPB, sehingga aktivitas pengembangan aplikasi berbasis web berikutnya
dapat lebih cepat dilakukan dan dinamis terhadap perubahan proses bisnis.
Kata kunci: Software reuse, Mekanisme Arsitektur, Pengembangan aplikasi
SUMMARY
FRANS RUDOLF BANJARNAHOR. Software Reuse Architectural Mechanism Development in Web Application Development (Case Study in Directorate of Human Resources IPB). Suppervised by YANI NURHADRYANI and IRMAN HERMADI.
Currently, software development practices increasingly worrying. This is due to the high cost and poor productivity because of repetitions of software development. Software reuse is one of the solutions to this problem. Software reuse is to reuse all or some of the things on the software using the previous resources and
the domain knowledge that has reusable value or to design new software by
applying the principle of reusability. Software reuse aims at improving quality and productivity software by using the being constantly developed techniques and strategies. The concept of software reuse has been widely used for a while, actually, it has been used since the programmer creates line of a program and then reuse either for the addition of new functions, or simply using prior knowledge to develop others.
Since 2003, IPB’s vision and mission have defined a pillar called the Centralized Administration and Decentralization Academic and Research. In order to support its vision and mission, continuous improvement and development of information system has been being conducted, especially on the web-based information systems. This increase has constraints in terms of resources, data and system integration as well as a business process that can occur at any time.
Application of software reuse in the development of web-based applications with a case study on information systems in the Directorate of Human Resources is an initialization phase of software reuse that produces an architectural mechanism in the development of web applications. In this study, the research method consists of: the designing of architectural mechanism, the selection of the used technology, the implementation of reuse assets, and the testing of reuse assets by creating a web application. The implementation stage resulted reuse assets: accesses to the database asset (based on the analysis on the domain problem) and presentation asset (interface). The next stage is to conduct tests on these assets by creating a web application project in the mechanism of distribution and utilization of assets through a repository server. The project is Human Resource Information System (HRIS) which is called in Bahasa Indonesia SIMPEG (Sistem Informasi dan Manajemen Kepegawaian) and its related application Executive Agenda Management System which is called in Bahasa Indonesia SMAP (Sistem Manajemen Agenda Pimpinan). The development of software reuse architectural mechanism in this study is expected to minimize the constraints of web development which is currently happening in IPB, so that the activity of next web-based application development can be more quickly and dynamically done toward the changing of business processes.
© Hak Cipta Milik IPB, Tahun 2015
Hak Cipta Dilindungi Undang-Undang
Dilarang mengutip sebagian atau seluruh karya tulis ini tanpa mencantumkan atau menyebutkan sumbernya. Pengutipan hanya untuk kepentingan pendidikan, penelitian, penulisan karya ilmiah, penyusunan laporan, penulisan kritik, atau tinjauan suatu masalah; dan pengutipan tersebut tidak merugikan kepentingan IPB
Tesis
sebagai salah satu syarat untuk memperoleh gelar Magister Komputer
pada
Program Studi Ilmu Komputer
PENGEMBANGAN MEKANISME ARSITEKTUR SOFTWARE REUSE
DALAM PENGEMBANGAN APLIKASI WEB
(STUDI KASUS DIREKTORAT SUMBER DAYA MANUSIA IPB)
SEKOLAH PASCASARJANA INSTITUT PERTANIAN BOGOR
BOGOR 2015
Judul Tesis : Pengembangan Mekanisme Arsitektur Software Reuse Dalam
Pengembangan Aplikasi Web (Studi Kasus Direktorat Sumber Daya Manusia IPB)
Nama : Frans Rudolf Banjarnahor NIM : G651120201
Disetujui oleh Komisi Pembimbing
Dr Yani Nurhadryani, SSi MT
Ketua Irman Hermadi, SKom MS PhD Anggota
Diketahui oleh
Ketua Program Studi Ilmu Komputer
Dr Eng Wisnu Ananta Kusuma, ST MT
Dekan Sekolah Pascasarjana
Dr Ir Dahrul Syah, MScAgr
PRAKATA
Puji dan syukur Penulis panjatkan kepada Tuhan atas segala curahan rahmat dan karunia-Nya sehingga sehingga karya ilmiah ini berhasil diselesaikan. Tema yang dipilih dalam penelitian yang dilaksanakan sejak bulan Desember 2013 ini ialah Software Reuse dengan judul Pengembangan Mekanisme Arsitektur Software Reuse Dalam Pengembangan Aplikasi Web (Studi Kasus Direktorat
Sumber Daya Manusia IPB)
Terima kasih penulis ucapkan kepada Ibu Dr Yani Nurhadryani, SSi MT dan Bapak Irman Hermadi, SKom MS PhD selaku pembimbing serta Dr Eng Wisnu Ananta Kusuma, ST MT sebagai penguji. Di samping itu, penghargaan penulis sampaikan kepada Direktorat Sumber daya manusia dan Direktorat Integrasi Data dan Sistem informasi yang telah membantu selama pengumpulan data. Ungkapan terima kasih juga disampaikan kepada orang tua, istri dan putri kembarku, Rekan-rekan bimbingan di Laboratorium SEIS, Rekan-rekan Magister Komputer angkatan 2012 atas segala doa dan kasih sayangnya
Semoga karya ilmiah ini bermanfaat.
Bogor, Mei 2015
DAFTAR ISI
DAFTAR TABEL iii
DAFTAR GAMBAR iii
DAFTAR LAMPIRAN iv
1 PENDAHULUAN 1
Latar Belakang 1
Perumusan Masalah 4
Tujuan Penelitian 4
Manfaat Penelitian 4
Ruang Lingkup Penelitian 4
2 TINJAUAN PUSTAKA 5
Mekanisme Arsitektur pada Pengembangan Perangkat Lunak 5
Multi Layered Architecure 5
Paradigma Berorientasi Objek 6
Object-Relational ImpedanceMismatch (Paradigm Mismatch) 6
Object Relational Mapping (ORM) 7
Design Pattern 8
Data Access Object (DAO) Pattern 9
3 METODE 11
Perancangan Mekanisme Arsitektur 11
Analisis Domain Kepegawaian 11
Domain Masalah Lainnya 12
Pemilihan Teknologi dan Tools 12
Implementasi 12
Pengujian 12
4 HASIL DAN PEMBAHASAN 13
Mekanisme Arsitektur Software Reuse 13
Teknologi dan Tools yang digunakan 13
Model Konseptual Kepegawaian 14
Implementasi 18
Proyek DAO (Data Access Object) dan Proyek Domain 18
Proyek Presentasi 20
Repository 23
Pengujian 24
DAFTAR ISI (lanjutan)
5 SIMPULAN DAN SARAN 25
Simpulan 25
Saran 26
DAFTAR PUSTAKA 27
iii
DAFTAR TABEL
1. Aplikasi yang berkaitan dengan SIMPEG 3
2. Lima masalah ketidaksesuaian antar model objek dan relasi
(Hibernate 2015) 7
3. Ruang Lingkup Design Pattern Gamma et al. (1994) 8
4. Teknlogi dan Tools java yang digunakan 13
5. Lanjutan Teknologi dan Tools java yang digunakan 14
6. Struktur Hirarki pustaka domain menggunakan maven 20
DAFTAR GAMBAR
1. Area penerapan Software Reuse (Sommerville 2007) 1
2. IPB Architecture Service (IAS)(DIDSI 2014) 3
3. Tiga Tahapan pada Mekanisme Arsitektur (EPF 2015) 5 4. Layered architecure (Enterprise Layer) pada DDD (Evans 2004) 5
5. MVC Design Pattern (Gamma et al. 1994) 9
6. Mekanisme tradisonal untuk melakukan akses ke DBMS 9 7. Mekanisme dengan menggunakan DAO untuk melakukan akses
DBMS 10
8. DAO Pattern (Deepak et al. 2001) 10
9. DAO Sequence Diagram (Deepak et al. 2001) 10
10.Metode Penelitian 11
11.Mekanisme Arsitektur Software Reuse 13
12.Model Konseptual Pegawai 15
13.Model Konseptual Struktur Organisasi 16
14.Model Konseptual Gaji 16
15.Model Konseptual Presensi dan Kinerja 17
16.Model Konseptual Penugasan 17
17.Model Konseptual Agenda Pimpinan 18
18.Kelas DAO (Data Access Object) 19
19.Proses Bisnis Pegawai 20
20.Implementasi Proyek Presentation 21
21.Persentasi Menu 21
22.Aset Persentasi Form 22
23.Presentasi Masukkan Tanggal 22
24.Persentasi live-search dan upload 22
25.Aset presentasi grid-nav, grid, grid-page 23
26.Mekanisme produksi dan distribusi aset 24
27.Aplikasi web SIMPEG 24
DAFTAR LAMPIRAN
1. Aset Akses ke basidata menggunakan DAO Manager 29
2. Aset Presentasi dalam TLD 32
1
PENDAHULUAN
Latar Belakang
Dalam rekayasa perangkat lunak salah satu aktivitas fundamentalnya adalah pembuatan atau pengembangan perangkat lunak itu sendiri. Enam puluh persen (60%) dari biaya keseluruhan aktivitas rekayasa perangkat lunak merupakan biaya pengembangan (development) (Sommervile 2011). Beragam metode dan teknik
dikembangkan disesuaikan dengan jenis perangkat lunak yang dibuat. Praktek pengembangan perangkat lunak menjadi semakin mengkhawatirkan dengan biaya yang tinggi, produktivitas yang buruk dan tidak konsisten (Biggerstaff & Richter 1987; Frakes & Isoda 1994; Lim 1994; Rine 2007; Poulin 2006) dengan membangun sistem yang hampir sama secara berulang-ulang.
Software reuse adalah penggunaan kembali segala hal atau pengetahuan
pada perangkat lunak sebelumnya untuk membuat perangkat lunak baru (Peterson 1992; Frakes & Kang 2005). Aset dalam software reuse dapat berupa perangkat
lunak itu sendiri atau knowledge pada perangkat lunak. Reusability merupakan
atribut dari aset perangkat lunak yang memiliki probabilitas terhadap reuse. Software reuse bertujuan untuk meningkatkan kualitas dan produktivitas
perangkat lunak, dan menjadi semakin menarik karena perangkat lunak yang dibangun pada organisasi atau perusahaan semakin besar dan semakin kompleks, tetapi ingin lebih murah dan dapat digunakan tepat waktu (Frakes & Kang 2005). Pada proyek RiSE (Reuse in Software Enginnering) (Garcia et al. 2007) tingkatan software reuse didefinisikan dalam bentuk maturity model (ad-hoc, basic reuse, initial reuse, organized reuse, systematic reuse) dimana tiap tingkatan memiliki
tujuan, perspektif (organisasi, bisnis, dan proses), dan praktis yang semakin matang.
Selama dua puluh tahun terakhir, banyak teknik dikembangkan untuk mendukung konsep reuse. Teknik-teknik tersebut menunjukan fakta bahwa
perangkat lunak dalam domain atau proses bisnis yang sama memiliki potensi penerapan reuse (Sommerville 2011). Penerapan reuse memiliki tingkatan yang
berbeda mulai dari fungsi sederhana sampai aplikasi. Beberapa komponen standar dibuat untuk memfasilitasi hal ini. Pada Gambar 1 terdapat area penerapan
software reuse, dan untuk menentukan area yang paling tepat dalam
mengimplementasikan software-reuse bergantung pada kebutuhan-kebutuhan
perangkat lunak yang dikembangkan, teknologi dan aset reuseable yang tersedia
dan pengalaman tim pengembang (Sommerville 2007).
Saat ini penggunaan aplikasi web dalam pengembangan sistem informasi lebih banyak digunakan karena kemudahan dalam mendistribusikan ke banyak pengguna tanpa harus melakukan konfigurasi di sisi pengguna. Berbagai teknologi dan tools dikembangkan untuk mempermudah pengembangan aplikasi web dan
mengakses aplikasi web tersebut. Misalnya web framework seperti Yii,
CodeIgniter, Symfoni pada PHP (http://www.phpframeworks.com/), atau Spring MVC, Java Servlet Faces, Struts 2, Google Web Toolkit pada java. Selain web framework pengembangan antarmuka juga menjadi lebih mudah dengan adanya
teknologi web yang semakin kaya akan fitur terutama antar muka yang lebih responsif dan interaktif sehingga membuat program lebih mudah digunakan dan lebih berfungsi dari sudut pengalaman pengguna (Paulson 2005). Pengembangan Ajax (Asynchronous JavaScript and XML) sejak tahun 1990 membawa para
pengembang aplikasi berbasis web dapat membuat aplikasi seperti layaknya aplikasi desktop. Ajax sendiri merupakan teknologi dalam web yang dapat
digunakan untuk meningkatkan hasil dan interaktifitas antarmuka yang lebih responsif.
Institut Pertanian Bogor (IPB), merupakan salah satu lembaga perguruan tinggi yang memiliki visi “Menjadi Perguruan Tinggi Berbasis Riset, Bertaraf Internasional dan Penggerak Prima Pengarusutamaan Pertanian”. Untuk memenuhi visi tersebut, salah satu misinya adalah “Memperkuat sistem manajemen perguruan tinggi yang efektif, efisien, transparan, dan akuntabel” (IPB 2015). Salah satu pilar untuk mendukung misi tersebut adalah Pilar Penguatan Sistem Manajemen yang menerapkan konsep Sentralisasi Administrasi dan Desentralisasi Akademik dan Riset (SADAR) yang telah dilakukan sejak tahun 2003 (RKA IPB 2013). Peningkatan pengembangan sistem informasi berbasis web di Institut Pertanian Bogor (IPB) secara signifikan terjadi pada tahun 2008 (DKSI 2008) dan sampai saat ini permintaan pembuatan sistem informasi terus meningkat terutama sistem informasi berbasis web (Web Application) baik dari
organisasi internal, maupun dari luar organisasi IPB (DKSI 2012). Saat ini pengembangan sistem informasi di IPB dikembangkan oleh pegawai (programmer) dengan sumber daya yang terbatas dan pengetahuan teknologi web
yang heterogen (Uraian Tugas Staf DKSI 2012). Selain hal tersebut isu integrasi data dan sistem informasi menjadi pekerjaan rumah yang harus segera terlaksana agar semakin memperkuat manajamen pengelolaan dan administrasi di IPB.
3
Gambar 2 IPB Architecture Service (IAS)(DIDSI 2014)
Pengembangan sistem informasi dalam mendukung administrasi perguruan tinggi sesuai dengan aturan yang berlaku dapat sangat dinamis mengalami perubahan hal ini juga terjadi di IPB. Pada prakteknya juga, pengembangan aplikasi web di IPB sering membangun aplikasi web yang hampir sama secara berulang-ulang (kode program, basis data, dan desain). Pada penelitian ini obyek penelitian difokuskan pada domain permasalahan kepegawaian pada Sistem Informasi Manajemen Kepegawai (SIMPEG) yang berada pada urutan ke-4 yaitu Kepegawaian yang dikelola oleh Direktorat Sumber Daya Manusia (SDM) sebagai tahapan inisialisasi.
SIMPEG saat ini merupakan aplikasi yang hanya sebatas mengelola data dan informasi pegawai dengan status PNS. Aplikasi lainnya yang lebih spesifik dalam mendukung aplikasi SIMPEG terdiri dari aplikasi yang dibuat secara terpisah dan sangat heterogen terutama pada bahasa pemrograman yang digunakan seperti terlampir pada Tabel 1.
Tabel 1 Aplikasi yang berkaitan dengan SIMPEG
Nama Sistem Bahasa Platform
Pemrograman DBMD Web Server
SIMPEG PHP SQL Server Apache
DUPAK ASP .NET SQL Server IIS
Kinerja Pegawai Java EE SQL Server Apache Tomcat
KGB Java EE SQL Server Apache Tomcat
Payroll PHP SQL Server Apache
Perumusan Masalah
Berbekalkan latar belakang dan kerangka pikir masalah yang diteliti dapat dirumuskan bagaimana merancang dan mengimplementasikan software reuse
dalam suatu mekanisme arsitektur untuk memenuhi kebutuhan dalam pengembangan sistem informasi berbasis web di IPB dengan memanfaatkan teknologi yang berkembang saat ini menjadi suatu aset reuse yang dapat
digunakan dalam pengembangan aplikasi web.
Tujuan Penelitian
Penelitian ini bertujuan menghasilkan mekanisme arsitektur software reuse
dalam pengembangan aplikasi web yang berimplikasi terhadap pola pengembangan yang reuseable serta mengarah ke sistem informasi yang
terintegrasi. Penelitian ini merupakan tahapan inisialisasi penerapan software reuse dengan studi kasus sistem informasi pada Direktorat Sumber Daya Manusia
IPB.
Manfaat Penelitian
Manfaat dari penelitian ini agar aktivitas pengembangan aplikasi web dapat lebih cepat, mudah, lebih teruji dan meminimalisir pengembangan secara berulang serta dinamis terhadap perubahan-perubahan proses bisnis.
Ruang Lingkup Penelitian
Ruang lingkup pada penelitian ini adalah:
1. Menggunakan dokumen, data dan aplikasi kepegawaian yang berjalan saat ini yang dikelola oleh Direktorat Sumber Daya Manusia (SDM).
2
TINJAUAN PUSTAKA
Mekanisme Arsitektur pada Pengembangan Perangkat Lunak
Mekanisme arsitektur adalah solusi umum untuk masalah-masalah yang digunakan selama pengembangan untuk meminimalkan kompleksitas (EPF 2015). Mekanisme Arsitektur pada perangkat lunak dapat menunjukan pola struktur dan perilaku dalam pengembangan perangkat lunak untuk membentuk dasar yang dapat diterapkan secara konsisten pada seluruh produk yang akan dikembangkan. Mekanisme arsitektur memiliki tiga tahapan yaitu: analisis, perancangan dan implementasi seperti pada Gambar 3.
Gambar 3 Tiga Tahapan pada Mekanisme Arsitektur (EPF 2015)
Multi Layered Architecure
Multi Layered Architectured merupakan arsitektur perangkat lunak yang
terdiri dari beberapa lapisan untuk memisahkan area pekerjaan pada pengembangan perangkat lunak. secara umum pengembangan sistem informasi dengan menggunakan perancangan berorientasi objek terdiri dari: Presentation Layer, Application Layer Bussiness Layer dan Data Access Layer. Contoh dari Multi Layered Architectured ini dapat dilihat pada enterprise layer (layered architecure) pada Domain-Driven Design (DDD) (Evans 2004) yang terdiri dari Domain, User Interface (Presentation), Application dan Infrastructure seperti
pada Gambar 4.
Paradigma Berorientasi Objek
Penggunaan “objek” merupakan hal utama didalam sistem berorientasi objek, tetapi konsep ini tidak begitu jelas dalam setiap paradigma berorientasi objek, bahkan dapat dikatakan bahwa paradigma ini tidak ditemukan tetapi berkembang dengan meningkatkan praktik yang sudah ada (Capretz 2003). Istilah objek muncul secara independen diberbagai cabang ilmu komputer. Penggunaan objek muncul pada beberapa area seperti: simulasi sistem, sistem operasi, data abtraksi dan kecerdasan buatan sejak tahun 1970-an. Orientasi objek mengatasi kompleksitas pada perangkat lunak yang merepresentasikan objek sebagai komponen abstrak pada perangkat lunak.
Terminologi orientasi objek dapat berbeda makna untuk menggambarkan sistem perangkat lunak dalam hal konsep berorientasi objek. Pada beberapa terminologi, konsep objek hanyalah nama baru untuk menggambarkan tipe data abstrak, pada terminologi lain kelas dan objek merupakan bentuk konkrit dimana dalam pandangan ini setiap objek dianggap unsur tipe yang dengan sendirinya dapat berelasi dengan subtype dan supertype. Pada kosep lainnya, sistem
berorientasi objek merupakan cara untuk melakukan organisasi dan sharing kode
program pada sistem perangkat lunak yang besar.
Rentsch (1982) mendefinisikan pemrograman berorientasi objek dalam bentuk inheritance, encapsulation, methods dan message yang dapat ditemukan
pada Smalltalk. Pascoe (1986) dengan menggunakan perspektif pada Smalltalk mendifinisikan orientasi objek dalam bentuk encapsulation, data abstraction, methods, messages, inheritance dan dynamic binding. Ada banyak interpretasi
yang berbeda terhadap paradigma berorientasi objek (Robson 1981; Thomas 1989; Stroustrup 1988; Nygaard 1986; Madsen dan Moller-Peddersen 1988; Cardelli dan Wegner 1985) namun ada satu hal yang sama yaitu tentang konsep primitif dari orientasi objek, yaitu objek merupakan enkapsulasi data yang di lindungi dengan operasi-operasi yang memiliki akses terhadap informasi yang disembunyikan.
Paradigma berorientasi objek sangat erat kaitannya dengan software reuse
karena menawarkan konsep inheritance, interface, polymorphism yang sangat
mendukung dalam penerapan software reuse (Meyer 1987; Johnson & Foote
1988; Sodhi J & Sodhi P 1999). Johnson & Foote (1988) juga mendefinisikan
framework reuse dalam bentuk white-box reuse dan black-box reuse. White-box reuse merupakan kerangka dimana untuk melakukan implementasinya harus
memahami cara membuat dan menggunakannya sehingga dapat dimodifikasi kembali pada proyek yang berbeda, sedangkan pada black-box reuse tidak perlu
mengetahui cara pembuatannya tetapi mengetahui cara menggunakannya. Kerangka pada black-box reuse tidak dapat dimodifikasi pada proyek yang
berbeda.
Object-Relational ImpedanceMismatch (Paradigm Mismatch)
7
tabel dalam bentuk tabular yang saling berelasi untuk menyimpan data. Pada pemrograman berorientasi objek ketika data ingin selalu dapat digunakan dan disimpan dikatakan persistance. RDBMS merupakan persistance paling umum
digunakan. Object-relational impedance mismatch merupakan kumpulan teknik
dan konsep ketika ingin menggunakan RDBMS dengan pemrograman berorientasi objek karena model objek dan model relasi tidak dapat digunakan secara bersamaan. Ada lima masalah ketidaksesuaian antara model objek dan relasi tersaji pada Table 2.
Tabel 2. Lima masalah ketidaksesuaian antar model objek dan relasi (Hibernate 2015)
Impedance Mismatch Objek Relasi
Granularity Terdiri Berbagai
tingkatan granularity,
dalam satu tabel dapat terdiri dari beberapa kelas objek
Terdiri dari dua level
granularity tabel dan
kolom
Subtype (inheritance) Terdapat mekanisme
inheritance
Tidak terdapat
mekanisme terhadap
inheritance
Identity Identitas menggunakan
Identity, equality
Identitas (Sameness)
menggunakan primary key
Asscociation Referensi dapat
dilakukan secara
Directional
Referensi menggunakan
Foriegn key dan tidak directional
Data navigation Mengakses data dari satu
relasi ke relasi lain dapat menggunakan atribut dari objek
Navigasi data
menggunakan Perintah
join pada SQL
menggunakan foreign-key
Object Relational Mapping (ORM)
Object / Relational Mapping (ORM) adalah teknik yang menyediakan
metodologi dan mekanisme untuk sistem berorientasi objek dalam menyimpan data jangka panjang ke basisdata (O’Neil 2008). Pendekatan ORM pertama kali diwujudkan dalam Hibernate (Bauer & King 2005) sebuah proyek open source
Design Pattern
Pada tahun 1970-an Christopher Alexander menulis beberapa buku yang mendokumentasikan patterns di dalam arsitektur teknik sipil, dan menyatakan
bahwa "Setiap pola menggambarkan masalah dari hal terjadi berulang-ulang di lingkungan kita, dan kemudian dapat menemukan solusi untuk masalah tersebut, dan dengan solusi tersebut dapat digunakan kembali secara berulang-ulang, tanpa pernah melakukannya dari awal dengan cara yang sama”. Mesikpun hal ini dikatakan dalam konteks bangunan di perkotaan komunitas perangkat lunak kemudian mengadopsi konsep tersebut.
Pattern merupakan segalah hal tentang masalah dan solusi, pattern
memungkinkan untuk mendokumentasikan masalah yang terjadi secara berulang dan solusi masalah tersebut dalam konteks tertentu (Deepak et al. 2001). Pattern
jika diterapkan pada orientasi objek secara umum memiliki elemen penting: (1) Nama Pola, (2) Masalah pada pola tersebut, (3) Solusi terhadap pola tersebut, dan (4) konsekuensi dari menerapkan pola solusi tersebut (Gamma et al. 1994).
Karena ada banyak pola desain, Gamma et al. (1994) mengklasifikasikan ruang
lingkup design pattern seperti pada Tabel 3 sehingga dengan klasifikasi tersebut
dapat membantu mempelajari pattern lebih cepat, dan dapat menemukan pattern
yang baru.
Tabel 3 Ruang Lingkup Design Pattern Gamma et al. (1994)
Purpose
Creational Structural Behavioral
Scope Class Factory Method Adapter Interpreter Template Method Object Abstract Factory
Builder
Chain of Responsibility Command
berpengaruh dalam bidang rekayasa perangkat lunak dan dianggap sebagai sumber penting bagi teori dan praktek desain berorientasi objek. Fowler (1997) mendefinisikan beberapa karakteristik dari pattern seperti:
- Diamati melalui pengalaman
- Ditulis dalam format yang terstruktur
- Mencegah membuat suatu hal yang sama secara berulang-ulang - Berada pada berbagai tingkatan abstraksi
- Menjalani perbaikan terus-menerus - Artifak yang dapat digunakan kembali
- Rancangan yang komunikatif dengan praktis yang lebih baik
9
Salah satu contoh pattern untuk mempermudah memahami tentang pattern
adalah MVC (Model/View/Controller) seperti pada Gambar 5 yang dikembangkan
pada smalltalk-80 yang memiliki tiga kelas objek dimana model merupakan objek
dari aplikasi, view sebagai presentasi (antarmuka) dari objek aplikasi, dan controller yang mengatur bagaimana antarmuka bereaksi terhadap masukan data
dan perintah dari pengguna. Meskipun MVC lebih awal dikembangkan, pattern
pada MVC lebih general. Jika dikaitkan dengan design pattern pada Tabel 3,
MVC pattern menggunakan Composite, Strategy, Factory method, dan Decorator pattern.
Gambar 5 MVC Design Pattern (Gamma et al. 1994)
Data Access Object (DAO) Pattern
DAO Pattern merupakan design pattern yang menangani mekanisme
abstraksi dan enkapsulasi antara kode program (Bussiness Object) dengan
mekanisme persistance seperti JDBC (Java Database Connectivity) (ORACLE
2002; Deepak et al. 2001). Pada DAO biasanya didefinisikan abstraksi dalam hal
transaksi data (create, read, update dan delete) sehingga kode program pada
aplikasi yang awalnya langsung berinteraksi dengan mekanisme persistance
seperti terlihat pada Gambar 6 diubah menjadi seperti pada Gambar 7. Hal ini bertujuan agar perubahan yang terjadi pada salah satu kode program atau DAO itu sendiri tidak harus merubah kode program secara keseluruhan.
Kode Program
DBMS
JDBC
Kode Program
DBMS
DAO JDBC
Gambar 7 Mekanisme dengan menggunakan DAO untuk melakukan akses DBMS
Representasi DAO pattern dalam bentuk kelas diagram dapat dilihat seperti
pada Gambar 8. Interaksi antara partisipan pada DAO pattern dapat terlihat seperti
pada Gambar 9.
BussinessObject DataAccessObject
ValueObject
DataSource
uses
obtains/modifies
creates/uses
encapsulates
Gambar 8 DAO Pattern (Deepak et al. 2001)
BussinessObject DataAccessObject DataSource
5:Set Data 1:Create
2:GetData 2.1:GetData
2.2:Create
ValueObject
3:Set Property
4:Set Property
5.1:Get Propery 5.2:Get Property 5.3:Get Property 2.3:Return Object
3
METODE
Metode pada penelitian ini dilakukan dengan tahapan seperti pada Gambar 10. Pendekatan yang dilakukan menggunakan paradigma berorintasi objek dengan kerangka white-box reuse. Pemilihan kerangka white-box reuse dipilih agar setiap
pengembang (programmer) dapat berkontribusi dalam membuat aset reuse dan
dapat dimodifikasi kembali jika programmer tersebut tidak berkerja lagi di IPB.
Analasis Domain Kepegawaian Perancangan
Mekanisme Arsitektur
Implementasi
Pengujian
Domain Presentation
Repository
Domain Masalah Lainnya
Pemilihan Teknologi dan Tools
Gambar 10 Metode Penelitian
Perancangan Mekanisme Arsitektur
Perancangan mekanisme arsitektur software reuse pada penelitian ini
menggunakan empat konsep lapisan layered architecure (enterprise layer) pada
DDD agar arisektur implementasi software reuse dapat memberikan fokus
terhadap area aset yang akan dikerjakan.
Analisis Domain Kepegawaian
Analisis domain kepegawaian merupakan tahapan untuk memodelkan studi kasus yang digunakan yaitu domain permasalahan kepegawaian menjadi model konseptual kepegawaian yang direpresentasikan dalam bentuk diagram kelas. Analisis domain merupakan metode utama untuk mewujudkan software reuse
yang lebih sistematis (Kang et al. 1990). Informasi tentang domain permasalahan
Domain Masalah Lainnya
Domain masalah lainnya adalah analisis yang dilakukan terhadap domain masalah lainnya yang berkaitan dengan IPB yang kedepan diharapkan juga dikembangan dengan prinsip software reuse dan menjadi bagian dalam
mekanisme arsitektur seperti Sistem informasi Akademik, Keuangan, Barang dan Aset serta sistem lainnya yang merupakan bagian proses bisnis di IPB. Tahapan ini belum dilakukan pada penelitian ini, didefinisikan untuk menggambarkan bahwa dalam mekanisme arsitektur ini tidak tertutup hanya pada domain kepegawaian saja.
Pemilihan Teknologi dan Tools
Tahapan ini adalah untuk menentukan teknologi dan tools yang digunakan
dalam pengembangan arsitektur (Almeida et al. 2007). Tools dan teknologi yang
digunakan dalam pengembangan aset menjadi penting ditentukan agar pengembang aset (reuse architect) dan pengguna aset (web developer) memiliki
bahasa dan pengetahuan yang sama dalam merancang dan menggunakan aset dengan kerangka white-box reuse.
Implementasi
Tahapan implementasi merupakan tahapan pengembangan aset reuse yang
dibagi ke dalam aktivitas pengembangan, yaitu:
1. Build for reuse: implementasi aset domain, antarmuka (presentation), utilitas
dalam bentuk library yang akan digunakan dalam pengembangan aplikasi web.
2. Impelementasi repository untuk melakukan manajemen terhadap aset reuse,
dan aset pengetahuan, serta mekanisme distribusi ke pengguna aset.
Pengujian
Pengujian adalah tahapan untuk melakukan uji hasil pada implementasi aset dengan membuat proyek aplikasi berbasis web (build with reuse) menggunakan
aset reuse pada implementasi menggunakan repository. Pada proyek aplikasi web
ini juga terdapat application layer yang merupakan lapisan yang melakukan
koordinasi terhadap aktivitas pada aplikasi web, tidak memiliki logika yang berhubungan dengan proses bisnis (domain permasalahan) seperti: validasi, penanganan session pengguna dan penanganan navigasi antara lapisan antarmuka
4
HASIL DAN PEMBAHASAN
Mekanisme Arsitektur Software Reuse
Dengan mengadopsi enterprise layer pada DDD, mekanisme arsitektur software reuse pada penelitian ini dirancang seperti pada Gambar 11. Tiap lapisan
pada enterprise layer dibuat dalam proyek terpisah. Setiap proyek akan
menghasilkan aset (pustaka) yang dapat digunakan kembali pada pengembangan aplikasi web pada Direktorat Sumber Daya Manusia atau web aplikasi yang lain.
Pustaka Domain Pustaka Antarmuka Pustaka DAO
Pengembangan Aplikasi Web
Proyek Domain Proyek Presentasi Proyek DAO
Presentasi
Application Layer
Domain
Repository
Implementasi Aset
Utilitas
Pustaka Utilitas
Dokumentasi Source Code Management
Infrastructure Layer
Gambar 11 Mekanisme Arsitektur Software Reuse
Teknologi dan Tools yang digunakan
Teknologi dan Tools yang digunakan dalam implementasi aset
menggunakan Java EE (Enterprise Edition). Pemilihan Java terkait dukungan
komunitas yang luas dan sampai saat ini masih merupakan teknologi yang tidak berbayar serta bersifat multi-platfom. Tools yang digunakan pada implementasi
mekanisme arsitektur tersaji pada Tabel 4 dan Tabel 5. Tabel 4 Teknologi dan tools java yang digunakan
Tools Produk Digunakan untuk
IDE Eclipse Java EE Pengembangan aset
Akses Data Hibernate Hibernate Tools ORM, Pemetaan Model Konseptual ke basis data Manajemen
Tabel 5 Lanjutan Teknologi dan Tools java yang digunakan
Tools Produk Digunakan untuk
Repository
Artifactory, Git-scm (GitBlit), Custom Web Tutorial
Kontrol terhadap public library,
manajemen pustaka, penyimpanan kode sumber, dokumentasi kode program dan tutorial penggunaan
Front-end
framework Boostrap, Jquery Digunakan sebagai antarmuka
MVC Struts2, Freemarker User Design, Interface Application LayerComponent, Template
Model Konseptual Kepegawaian
Model konseptual kepegawaian merupakan diagram kelas hasil analisis permasalahan domain kepegawaian yang dikelompokan ke dalam sub-domain permasalahan. Model konseptual yang dilakukan pada penelitian terdiri dari:
Model Konseptual Pegawai
Model Konseptual Pegawai merupakan model konseptual yang berkaitan dengan informasi pegawai seperti: biodata, administratif kepegawaian terlihat pada Gambar 12. Pegawai di IPB terdiri dari: PNS (Dosen, dan Tendik), Pegawai Non-PNS (Dosen dan tendik), dan pegawai dengan kontrak kerja. Model konseptual pegawai dihasilkan dari sumber acuan pada Undang-Undang Republik Indonesia Nomor 5 Tahun 2014, existing data, Form Isian Pegawai Negeri dari
Model Konseptual Stuktur Organisasi IPB
Model konseptual struktur organisasi IPB merupakan model konseptual untuk masalah perubahan struktur organisasi yang terjadi setiap periode kepemimpinan. Stuktur organisasi di IPB sangat dinamis mengalami perubahan. Hampir setiap periode kepemimpinan struktur organisasi di IPB mengalami perubahan baik akibat regulasi dari pemerintah pusat maupun kebutuhan untuk mendukung visi dan misi IPB. Model konseptual struktur organisasi IPB yang dihasilkan tersaji pada Gambar 13.
Gambar 13 Model Konseptual Struktur Organisasi
Model Konseptual Gaji
Gaji merupakan hal yang paling diharapkan oleh semua pegawai, Gaji pegawai di IPB yang terdiri dari PNS pusat diatur dalam PP Tentang Gaji PNS yang dikelompokan berdasarkan golongan, masa kerja, dan status pegawai (Fungsional, Struktural), gaji Non-PNS diatur menggunakan SK (Surat Keputsan) Rektor, dan gaji pegawai kontrak yang diatur berdasarkan SK Perjanjian Kontrak. Model konseptual pada domain permasalahan gaji yang dihasilkan tersaji pada Gambar 14.
17
Model Konseptual Presensi dan Kinerja
Presensi merupakan aktivitas pencatatan kehadiran pegawai pada hari kerja setiap bulan yang dicatat pada waktu datang dan waktu pulang menggunakan mesin fingerprint, website dan daftar kehadiran manual yang
diverifikasi oleh atasan langsung pegawai. Presensi digunakan sebagai salah satu komponen dalam menilai kinerja pegawai. Model konseptual yang dihasilkan tersaji pada Gambar 15.
Gambar 15 Model Konseptual Presensi dan Kinerja
Model Konseptual Penugasan
Penugasan merupakan aktivitas administratif penugasan pegawai mulai dari usulan sampai tahap SK (Surat Keterangan) penugasan dikeluarkan dalam melaksanakan aktifitas seperti: Tugas Belajar, Tugas kedinasan dan penugasan lainnya. Model konseptual yang dihasilkan tersaji pada Gambar 16.
Model Konseptual Agenda Pimpinan
Agenda pimpinan merupakan aktivitas dalam mencatat aktivitas yang berkaitan dengan jadwal pimpinan dan pejabat dilingkungan IPB dalam hal efektifitas untuk memonitoring jadwal pimpinan agar aktivitas pertemuan seperti rapat lebih efektif. Model konseptual agenda pimpinan tersasi pada Gambar 17.
Gambar 17 Model Konseptual Agenda Pimpinan
Model konseptual yang telah diutarkan diatas merupakan sebahagian dari model konseptual kepagawaian, sub-domain permasalahan lainnya dari kepegawaian belum dilakukan pada penelitian ini seperti: penelitian, karya ilmiah, daftar usulan penetapan angka kredit (DUPAK).
Implementasi
Proyek DAO (Data Access Object) dan Proyek Domain
DAO Pattern diimplementasikan menggunakan pustaka hibernate untuk
menghasilkan pustaka DAO (aset akses data ke RDMBS) melalui proyek DAO. Proyek DAO terdiri dari kelas-kelas seperti terlihat pada Gambar 18 DAO pattern
merupakan kelas interface dan kelas abstrak dengan pattern yang mengadopsi Abstract Factory dan Factory Method Pattern (Gamma et al. 1994). Aset pada
DAO terdiri dari:
1. DAO interface (DAO) merupakan kelas yang mendefinisikan operasi standar
yang akan dilakukan pada tiap model objek persistence
2. DAO Implementation (DAOImpl) merupakan kelas abstrak yang mengimplementasikan DAO interface. Kelas ini bertanggung jawab dalam
menghubungkan ke mekanisme persistence dengan ValueObject sebagai
19
Gambar 18 Kelas DAO (Data Access Object)
Model konseptual pada domain permasalahan yang telah dibuat sebelumnya yang dibuat dalam bentuk POJO (Plain Old Java Object) yang akan digunakan
Obyek yang dipetakan menjadi tabel ke dalam basis data. POJO yang dihasilkan terdiri dari kelas abstrak, kelas konkrit, kelas referensi dan kelas enumerasi. Kelas abstrak, kelas konkrit dan kelas referensi merupakan obyek pada model domain permasalahan yang memiliki file pemetaan ke table pada basisdata yang dipetakan
dan digeneralisasi oleh hibernate menggunakan hibernate tools plugin yang
tersedia pada Eclipse IDE menjadi NamaKelasModel.hbm.xml.
Kelas abstrak digunakan sebagai root pada model yang memiliki struktur
hampir sama, sedangkan kelas konkrit merupakan model spesifik yang mewakili model konkrit yang mewarisi kelas abstrak agar dapat diinstansiasi sebagai
ValueObject pada DAO. Kelas referensi merupakan kelas yang digunakan sebagai
atribut pada kelas abstrak maupun kelas konkrit.
Setiap sub-domain permasalahan kepegawaian dikelompokan kedalam
package. Setiap package terdiri dari kelas domain permasalahan yang saling
berelasi menggunakan hibernate association mappings strategy1 layaknya relasi
table pada basisdata. Relasi yang digunakan pada kelas abstrak terhadap kelas konkrit menggunakan hibernate inheritance strategy2. Pada model juga terdapat
kelas view (TransferObject) yang tidak berasosiasi dengan model inti dibuat untuk
membantu dalam merepresentasikan model dalam menampilkan data karena tidak semua atribut pada kelas model dibutuhkan.
Impelementasi proses bisnis pada setiap model domain permasalahan didefinisikan terpisah dengan membuat kelas interface dan kelas konkrit tersendiri
yang mewarisi DAO seperti pada Gambar 19 dan diimpementasikan pada kelas PrefixDomainDAOImpl.
1 https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/associations.html
Gambar 19 Proses Bisnis Pegawai
Pemanggilan PrefixDomainDAOImpl didefinisikan pada kelas manager dengan nama SubDomainFactory dengan menentukan sesi koneksi ke basistada yang digunakan seperti pada Lampiran 1. Dengan pola ini, perubahan-perubahan terhadap proses bisnis dapat ditambahkan ataupun tidak digunakan tanpa harus merubah struktur yang lain. Pola ini juga mempermudah akses ke basisdata karena untuk melakukan transaksi data dapat dilakukan dengan cara:
1. Instansiasi
PrefixDomainDAO dao = new SubDomainFactory.getPrefixDomainDAO(); List<KelasModel> listModel = dao.prosesBisnis(param1, param2); KelasModel kelasModel = dao.find(id);
dao.close();
2. Satu baris kode program
SubDomainFactory.getPrefixDomainDAO().prosesBisnis(param1, param2); SubDomainFactory.getPrefixDomainDAO().close();
Proyek dengan domain masalah lainnya dapat didefinisikan dengan penamaan domainpermasalahan-model menggunakan dependency terhadap
proyek DAO kemudian dikompilasi menggunakan maven menjadi pustaka domainpermasalahan-model-versi.jar. Struktur hirarki dari pustaka domain dibuat seperti pada Tabel 6.
Tabel 6 Struktur Hirarki pustaka domain menggunakan maven
Proyek Depedency Hasil proyek
Dao Pustaka hibernate dao-versi.jar, Dokumentasi pegawai-model dao-versi.jar Pegawai-model-versi.jar,
Dokumentasi model domain pegawai
domainpermasala
han-model dao-versi.jar domainpermasalahan-model-versi.jar, Dokumentasi
Proyek Presentasi
Implementasi aset antarmuka (presentation) dilakukan seperti pada Gambar
21
template dan theme pada Struts MVC (Model View Controller) Component3.
Desain antarmuka dibuat dalam bentuk template menggunakan pustaka antarmuka
seperti bootstrap dan jquery yang menerima parameter melalui komponen antarmuka. Komponen antarmuka digunakan untuk mengatur dan mengolah parameter antarmuka kemudian di petakan pada sebuah Tag Library Descriptor
(TLD).
Ekstraksi Website yang
sudah ada Kostumisasi template
Front-end framework
Komponen antarmuka menggunakan Komponen
antarmuka Struts
JSP Controller
atribut Referensi
Referensi
desain untuk desainDigunakan
Atribut desain
mapping
Akses data hasil
TLD
Tag, Parameter
Mapping
Gambar 20 Implementasi Proyek Presentation
Proyek presentasi menghasilkan pustaka antarmuka dengan nama ui-version.jar. Untuk menggunakan pustaka setiap response yang ditampilkan dalam
bentuk JSP (Java Servlet Pages) mendefinisikan baris kode yang merujuk ke TLD
(<%@taglib prefix="ipb" uri="/ipb-tags"%>). Dibawah ini tersaji aset presentasi yang paling umum digunakan dalam navigasi, masukan pengguna dan menampilkan informasi:
1. Aset presentasi menu, menu-group, menu-item dan menu-dropdown
Digunakan untuk menampilkan navigasi terhadap halaman website seperti pada Gambar
Gambar 21 Aset persentasi menu menu-group, menu-item dan menu-dropdown
2. Aset presentasi form, form-group, enum-selectbox, selectbox, textbox
Digunakan untuk masukan yang telah dikostumisasi sesuai kebutuhan seperti pada Gambar
Gambar 22 Aset persentasi elemen masukan pada form
3. Aset presentasi dialog, datepicker, datetimepicker
Digunakan untuk masukan tanggal dan jam seperti pada Gambar 23
Gambar 23 Aset presentasi dialog, datepicker, datetimepicker
4. Aset presentasi live-search, upload
Presentasi live-search digunakan untuk mekanisme pencarian data pada
masukan teks, yang dapat dipilih. Presentasi upload digunakan untuk mengunggah berkas. Kedua presentasi ini terlihat pada Gambar 24
23
5. Aset presentasi grid-nav, grid, grid-page
Aset presentasi grid-nav, grid, grid-page digunakan untuk menampilkan data dalam bentuk baris data (grid) yang dapat dilakukan penggolahan menggunakan navigasi pada grid-nav, dan ditampilakan perjumlah data pada grid-page seperti terlihat pada Gambar 25.
Gambar 25 Aset presentasi presentasi grid-nav, grid, grid-page
Dalam implementasi aset presentasi ini telah dihasilkan 36 aset presentasi terlampir pada Lampiran 2 Aset presentasi dalam TLD. Aset presentasi ini dapat digunakan pada setiap proyek aplikasi web dengan menggunakan platform yang
sama dengan yang digunakan pada penelitian ini.
Repository
Seluruh aktivitas dalam implementasi aset disimpan kedalam repository, repository merupakan mesin server yang berfungsi untuk:
1. Melakukan kontrol terhadap versi pustaka yang digunakan dalam pengembangan aset reuse.
2. Manajemen Pustaka (library): file berbentuk .jar yang dihasilkan dari
pengembangan aset sebagai pustaka (infrastructure layer) yang akan di
gunakan pada tiap proyek pengembangan aplikasi.
3. Sebagai media penyimpanan pengetahuan pengembangan yang terdiri dari: a. Sumber kode program: sekumpulan file yang disimpan secara utuh dari
proyek aset reuse pada Git-scm (source code management)
b. Dokumentasi, file berbentuk HTML, merupakan hasil generasi kode sumber pada aset reuse
c. Sebagai penyedia laman tutorial penggunaan aset.
Mekanisme produksi dan distribusi aset pada repository terlihat seperti pada
Gambar 26. Reuse Architect mendefinisikan aset reuse dan melakukan kompilasi
yang menghasilkan pustaka ke local repository. Selain pustaka dokumentasi
penggunaan serta fungsi pada tiap kode program (Application Programming Interface (API)) disimpan pada repository.
Pengembang web (web developer) menggunakan pustaka dan informasi
penggunaan pada layanan pada server repository. Layanan repository yang
Public Maven Repository
Gambar 26 Mekanisme produksi dan distribusi aset
Pengujian
Pengujian dilakukan untuk memastikan mekanisme arsitektur dapat digunakan. Pengujian dilakukan dengan cara membuat proyek aplikasi web menggunakan aset reuse yang telah dibuat pada implementasi. Pada penelitian ini
dibuat dua aplikasi web yaitu.
Aplikasi web Sistem Informasi Manajemen Kepegawaian (SIMPEG)
Aplikasi web SIMPEG merupakan aplikasi yang mengelola data dan informasi pegawai seperti pada Gambar 27. Aplikasi web ini dapat diakses pada alamat http://172.17.0.121/simpeg/ menggunakan jaringan lokal di IPB. Aplikasi web SIMPEG ini masih merupakan prototipe yang penggunaan dan pengembangan lebih lanjut terkait kebijakan internal pengembangan sistem informasi di IPB.
25
Aplikasi Sistem Manajemen Agenda Pimpinan (SMAP)
Aplikasi web Sistem Manajemen Agenda Pimpinan (SMAP) merupakan aplikasi web yang mengelola agenda pimpinan dan pejabat di IPB. Aplikasi web SMAP juga menggunakan aset yang sama pada implementasi seperti yang digunakan pada aplikasi web SIMPEG. Aplikasi web ini bertujuan untuk memberikan informasi jadwal pimpinan agar lebih efisien dalam kegiatan seperti rapat dan pertemuan antar pimpinan dan pejabat. Aplikasi web ini dapat diakses pada alamat http://smap.ipb.ac.id menggunakan jaringan lokal di IPB seperti terlihat Gambar 28. Aplikasi web SMAP ini sudah digunakan sejak bulan Desember 2014.
Gambar 28 Aplikasi web SMAP
5
SIMPULAN DAN SARAN
Simpulan
Penelitian ini menghasilkan mekanisme arsitektur software reuse yang
bermanfaat dalam aktivitas pengembangan aplikasi web karena akses ke basis data dan desain antarmuka web dapat lebih mudah dilakukan dengan menambahkan pustaka aset domain dan aset presentasi melalui local repository pada tiap proyek
pengembangan aplikasi yang berkaitan dengan Direktorat Sumber Daya Manusia dalam hal ini pengembangan SIMPEG.
Prototipe aplikasi web SIMPEG dan aplikasi web SMAP yang telah dilakukan membuktikan bahwa mekanisme arsitektur reuse yang dilakukan
menerapkan prinsip dari software reuse. Hal ini dapat dilihat pada aplikasi web
SMAP yang menggunakan aset akses data pada kepegawaian dan menggunakan presentasi yang sama seperti pada protitipe SIMPEG. Selain hal tersebut fokus utama penelitian tentang software reuse juga dapat dibuktikan bahwa dengan
tingkatkan dengan adanya repository yang menyediakan akses aset, pengetahuan
pengembangan dan penggunaan menjadi lebih terorganisasi.
Saran
Penelitian ini merupakan tahapan ad-hoc dan basic reuse jika dikaitkan
dalam software reuse maturity model. Beberapa saran yang dapat dilakukan pada
penelitian selanjutnya adalah:
1. Mengembangkan software reuse untuk menghasilkan aset client scripting.
2. Melakukan penelitian berupa evaluasi software quality metrics terhadap kode
27
DAFTAR PUSTAKA
Almeida ES, Alvaro A, Garcia VC, Burégio VA, Nascimento LM, & Lucrédio D. 2007. CRUISE: Component Reuse in Software Engineering.
Bauer C & King G. 2005. Hibernate in action. Greenwich, CT: Manning
Biggerstaff TJ & Richter C. 1987. Reusability framework, assessment and directions. IEEE Software. 4(2):41–49.
Capretz LF. (2003). A brief history of the object-oriented approach. ACM SIGSOFT Software Engineering Notes. 28(2): 6.
Cardelli L & Wegner P. 1985. On understanding types, data abstraction, and polymorphism. ACM Computing Surveys (CSUR). 17(4): 471-523.
Deepak A, Crupi J, & Malks D. 2001. Core J2EE Patterns: Best Practices and Design Strategies. Sun Microsystems. Palo Alto.
[DKSI IPB] Direktorat Komunikasi dan Sistem Informasi Institut Pertanian Bogor. 2008. Laporan Akhir 2008-2012. Bogor (ID): DKSI IPB
[DKSI IPB] Direktorat Komunikasi dan Sistem Informasi Institut Pertanian Bogor. 2012. Uraian Tugas DKSI. Bogor (ID): DKSI IPB
[DIDSI IPB] Direktorat Integrasi Data dan Sistem Informasi Institut Pertanian Bogor. 2014. IPB Architecture Service (IAS). Bogor (ID): DIDSI IPB
[EPF] Eclipse Process Framework. Concept: Architectural Mechanism [internet]. [diacu 2015 Februari 10]. Tersedia dari:
http://epf.eclipse.org/wikis/openup/core.tech.common.extend_supp/guidances /concepts/arch_mechanism_2932DFB6.html.
Evans E. 2014. Domain-driven design: tackling complexity in the heart of software. Addison-Wesley Professional.
Fowler M. 1997. Analysis patterns: reusable object models. Addison-Wesley Professional.
Frakes WB, & Isoda S. 1994. Success factors of systematic reuse. Software, IEEE.
11(5): 14-19.
Frakes WB, & Kang K. 2005. Software reuse research: Status and future. Software Engineering,IEEE Transactions. 31(7):529-536.
Gamma E, Helm R, Johnson R, & Vlissides J. 1994. Design patterns: elements of reusable object-oriented software. Pearson Education.
Garcia VC, Lucrédio D, Alvaro A, De Almeida ES, de Mattos Fortes RP, & de Lemos Meira SR. 2007. Towards a Maturity Model for a Reuse Incremental Adoption. Di dalam: SBCARS. hlm 61-74.
HIBERNATE. 2005. What is Object/Relational Mapping? [internet]. [diacu 2015 April 1 ] Tersedia dari: http://hibernate.org/orm/what-is-an-orm/
IPB. Institut Pertanian Bogor. 2015. Visi, Misi dan Kebijakan Mutu [internet]. [diacu 2015 Februari 03] Tersedia dari: http://ipb.ac.id/about/vision-and-mission
Johnson RE & Foote B. 1998. Designing reusable classes. Journal of object-oriented programming. 1(2): 22-35.
Kang KC, Cohen SG, Hess JA, Novak WE, & Peterson AS. 1990. Feature-oriented domain analysis (FODA) feasibility study (No. CMU/SEI-90-TR-21).
Lim WC. 1996. Reuse economics: A comparison of seventeen models and directions for future research. Di dalam: Proceedings Fourth International Conference IEEE. hlm 41-50.
Madsen OL, & Møller-Pedersen B. Januari 1988. What object-oriented programming may be-and what it does not have to be. Di dalam: ECOOP’88
European Conference on Object-Oriented Programming. Springer Berlin
Heidelberg. hlm 1-20
Meyer B. 1987. Reusability: The case for object-oriented design. IEEE Software.
4(2): 50-64.
[MSDN] Microsoft Developer Network. Entity Data Model [internet]. [diacu 2015 April 1]. Tersedia dari:
https://msdn.microsoft.com/en-us/library/vstudio/ee382825%28v=vs.100%29.aspx
Nygaard K. 1986. Basic Concepts in Object Oriented Programming. ACM Sigplan Notices. 12(10): 128-132
O'Neil EJ. Juni 2008. Object/relational mapping 2008: hibernate and the entity data model (edm). Di dalam: Proceedings of the 2008 ACM SIGMOD international conference on Management of data. hlm 1351-1356. ACM.
ORACLE. 2002. Core J2EE Patterns - Data Access Object [internet]. [diacu 2014 April 1] Tersedia dari:
http://www.oracle.com/technetwork/java/dataaccessobject-138824.html Pascoe G. (1986). Elements of object-oriented programming. Byte. 11(8):
139-144.
Paulson LD. 2005. Building rich web applications with Ajax. Computer. 38(10):
14-17.
Peterson AS. 1991. Coming to terms with software reuse terminology: a model-based approach. ACM Sigsoft software engineering notes. 16(2): 45-51.
Poulin JS. 2006. The business case for software reuse: Reuse metrics, economic models, organizational issues, and case studies. Di dalam Reuse of Off-the-Shelf Components Springer Berlin Heidelberg. hlm 439-439.
[RKA IPB] Rencana Kerja Anggaran Institut Pertanian Bogor. 2013. Rencana Kerja Anggaran 2013. Bogor (ID): IPB
Rentsch T. 1982. Object oriented programming. ACM Sigplan Notices. 17(9):
51-57.
Rine DC & Sonnemann RM. 1998. Investments in reusable software. A study of software reuse investment success factors. Journal of systems and software.
41(1): 17-32.
Robson D. Agustus 1981. Object-Oriented Software Systems. Byte. 6(8):74-86.
Sametinger J. 1997. Software engineering with reusable components. Springer Science & Business Media.
Sodhi, J & Sodhi P. 1999. Software reuse: domain analysis and design processes. New York: McGraw-Hill.
Sommerville I. 2007. Software Engineering. Harlow (EN):ADDISON-WESLEY.
Ed ke-8. 415-428
Sommerville I. Software Engineering. 2011. Harlow (EN):ADDISON-WESLEY.
Ed ke-9. 425-440.
Stroustrup B. 1988. What is object-oriented programming?. Software, IEEE. 5(3):
10-20.
29
Lampiran 1 Aset Akses ke basidata menggunakan DAO Manager
2. DAO Manager Struktur Organsasi yang digunakan pada proses bisnis Stuktur Organiasi
31
4. DAO Manager Gaji yang digunakan pada proses bisnis gaji pegawai
5. DAO Manager Agenda Pimpinan pada proses bisnis agenda pimpinan
Lampiran 2 Aset Presentasi dalam TLD
<?xml version="1.0" encoding="UTF-8"?>
<taglib version="2.1" xmlns="http://java.sun.com/xml/ns/javaee"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
1. Tag presentasi form login <tag>
2. Tag presentasi form login untuk unit kerja <tag>
3. Tag presentasi form login dengan navigasi register
33
4. Tag presentasi menampilkan data dalam bentuk list <tag>
<description>Menampilkan model dalam bentuk list</description>
5. Tag presentasi Menampilkan data dalam bentuk baris dan kolom <tag>
<name>grid</name>
<description>label model </description> <name>title</name>
6. Tag presentasi menampilkan data dalam bentuk baris dan kolom dalam bentuk
plain format
<tag>
35
<rtexprvalue>true</rtexprvalue> <type>java.util.List</type> </attribute>
<attribute>
<description>label model </description> <name>title</name>
7. Tag presentasi menampilkan data dalam bentuk baris dan kolom dengan kontrol tambahan (checklist)
<tag>
<rtexprvalue>false</rtexprvalue>
8. Tag presentasi untuk navigasi Tag grid dalam bentuk pagination number <tag>
<description>Menampilkan pagination grid data</description>
<name>grid-page</name>
9. Tag presentasi untuk navigasi tag grid dalam bentuk pagination number
<tag>
<description>Menampilkan navigasi pada grid data</description>
<name>grid-nav</name>
37
<body-content>scriptless</body-content> <attribute>
<description>label model </description> <name>title</name>
<description>true|false untuk pengaturan aktif tombol</description>
10.Tag presentasi untuk mengatur library javascript yang akan digunakan
</attribute>
11.Tag presentasi masukan teks <tag>
12.Tag presentasi masukan kontainer form <tag>
<name>form</name>
39
13.Tag presentasi masukan pilihan (selectbox) pada form
<name>rows</name>
41
16.Tag presentasi form pencarian
17.Tag presentasi menampilkan biodata pegawai <tag>
18.Tag presentasi kontainer menu <tag>
43
20.Tag presentasi item pada menugrup <tag>
21.Tag presentasi menu dalam bentuk dropdown
22.Tag presentasi pencarian pada navigasi menu
45
24.Tag presentasi masukan pengguna (selectbox) menggunakan kelas enumerasi
pada menu navigasi
25.Tag presentasi dialog
26.Tag presentasi masukan waktu berupa tahun, bulan dan tanggal
47
29.Tag presentasi kontainer dalam bentuk panel <tag>
</attribute>
31.Tag presentasi pencarian yang menampilkan hasil pencarian dengan kolom yang dapat ditentukan sebagai parameter ketika pengguna melakukan enter
49
32.Tag presentasi menampilkan kalender dalam satu bulan <tag>
33.Tag presentasi untuk melakukan upload file
<required>true</required>
34.Tag presentasi untuk menampilkan status sedang loading
<tag>
35.Tag presentasi untuk button dalam bentuk dropdown
<tag>
36.Tag presentasi masukan yang menerima nilai menggunakan slider
<tag>
<name>slider</name>
51
<name>id</name>
<required>true</required>
<rtexprvalue>false</rtexprvalue> </attribute>
<attribute>
<name>min</name>
<required>true</required>
<rtexprvalue>false</rtexprvalue> </attribute>
<attribute>
<name>max</name>
<required>true</required>
<rtexprvalue>false</rtexprvalue> </attribute>
<attribute>
<name>step</name>
<required>true</required>
<rtexprvalue>false</rtexprvalue> </attribute>
<attribute>
<name>initialValue</name> <required>true</required>
<rtexprvalue>false</rtexprvalue> </attribute>
<attribute>
<name>orientation</name>
<rtexprvalue>false</rtexprvalue> </attribute>
Lampiran 3 Layanan Repository
1. Portal untuk dapat mengakses re-source penggunaan aset menggunakan
custom web application (menggunakan aset reuse yang dibuat pada penelitian
ini)
53
3. Source Code Management menggunakan GitBlit untuk organisasi dan
distribusi kode program
4. Library Management menggunakan artifactory untuk organisasi dan distribusi
