Pengembangan Mekanisme Arsitektur Software Reuse Dalam Pengembangan Aplikasi Web (Studi Kasus Direktorat Sumber Daya Manusia Ipb).

PENGEMBANGAN MEKANISME ARSITEKTUR SOFTWARE REUSE
DALAM PENGEMBANGAN APLIKASI WEB
(STUDI KASUS DIREKTORAT SUMBER DAYA MANUSIA IPB)

FRANS RUDOLF BANJARNAHOR

SEKOLAH PASCASARJANA
INSTITUT PERTANIAN BOGOR
BOGOR
2015

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
NIM G651120201

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
Berbasis Web

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.
Keywords: Software reuse, architecural mechanisms, web application development

© 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
Dilarang mengumumkan dan memperbanyak sebagian atau seluruh karya tulis ini
dalam bentuk apa pun tanpa izin IPB

PENGEMBANGAN MEKANISME ARSITEKTUR SOFTWARE REUSE
DALAM PENGEMBANGAN APLIKASI WEB
(STUDI KASUS DIREKTORAT SUMBER DAYA MANUSIA IPB)

FRANS RUDOLF BANJARNAHOR

Tesis
sebagai salah satu syarat untuk memperoleh gelar
Magister Komputer
pada
Program Studi Ilmu Komputer

SEKOLAH PASCASARJANA
INSTITUT PERTANIAN BOGOR
BOGOR
2015

Penguji luar komisi pada Ujian Tesis: Dr Eng Wisnu Ananta Kusuma, ST MT

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

Dekan Sekolah Pascasarjana

Dr Eng Wisnu Ananta Kusuma, ST MT

Dr Ir Dahrul Syah, MScAgr

Tanggal Ujian: 5 Februari 2015

Tanggal Lulus:

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

Frans Rudolf Banjarnahor

DAFTAR ISI
DAFTAR TABEL

iii

DAFTAR GAMBAR

iii

DAFTAR LAMPIRAN

iv

1 PENDAHULUAN
Latar Belakang
Perumusan Masalah
Tujuan Penelitian
Manfaat Penelitian
Ruang Lingkup Penelitian

1
1
4
4
4
4

2 TINJAUAN PUSTAKA
Mekanisme Arsitektur pada Pengembangan Perangkat Lunak
Multi Layered Architecure
Paradigma Berorientasi Objek
Object-Relational Impedance Mismatch (Paradigm Mismatch)
Object Relational Mapping (ORM)
Design Pattern
Data Access Object (DAO) Pattern

5
5
5
6
6
7
8
9

3 METODE
Perancangan Mekanisme Arsitektur
Analisis Domain Kepegawaian
Domain Masalah Lainnya
Pemilihan Teknologi dan Tools
Implementasi
Pengujian

11
11
11
12
12
12
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
Aplikasi web Sistem Informasi Manajemen Kepegawaian (SIMPEG) 24
Aplikasi Sistem Manajemen Agenda Pimpinan (SMAP)
25

ii

DAFTAR ISI (lanjutan)
5 SIMPULAN DAN SARAN
Simpulan
Saran

25
25
26

DAFTAR PUSTAKA

27

RIWAYAT HIDUP

54

iii

DAFTAR TABEL
1. Aplikasi yang berkaitan dengan SIMPEG
2. Lima masalah ketidaksesuaian antar model objek dan relasi
(Hibernate 2015)
3. Ruang Lingkup Design Pattern Gamma et al. (1994)
4. Teknlogi dan Tools java yang digunakan
5. Lanjutan Teknologi dan Tools java yang digunakan
6. Struktur Hirarki pustaka domain menggunakan maven

3
7
8
13
14
20

DAFTAR GAMBAR
1.
2.
3.
4.
5.
6.
7.

Area penerapan Software Reuse (Sommerville 2007)
IPB Architecture Service (IAS) (DIDSI 2014)
Tiga Tahapan pada Mekanisme Arsitektur (EPF 2015)
Layered architecure (Enterprise Layer) pada DDD (Evans 2004)
MVC Design Pattern (Gamma et al. 1994)
Mekanisme tradisonal untuk melakukan akses ke DBMS
Mekanisme dengan menggunakan DAO untuk melakukan akses
DBMS
8. DAO Pattern (Deepak et al. 2001)
9. DAO Sequence Diagram (Deepak et al. 2001)
10. Metode Penelitian
11. Mekanisme Arsitektur Software Reuse
12. Model Konseptual Pegawai
13. Model Konseptual Struktur Organisasi
14. Model Konseptual Gaji
15. Model Konseptual Presensi dan Kinerja
16. Model Konseptual Penugasan
17. Model Konseptual Agenda Pimpinan
18. Kelas DAO (Data Access Object)
19. Proses Bisnis Pegawai
20. Implementasi Proyek Presentation
21. Persentasi Menu
22. Aset Persentasi Form
23. Presentasi Masukkan Tanggal
24. Persentasi live-search dan upload
25. Aset presentasi grid-nav, grid, grid-page
26. Mekanisme produksi dan distribusi aset
27. Aplikasi web SIMPEG
28. Aplikasi web SMAP

1
3
5
5
9
9
10
10
10
11
13
15
16
16
17
17
18
19
20
21
21
22
22
22
23
24
24
25

iv

DAFTAR LAMPIRAN
1. Aset Akses ke basidata menggunakan DAO Manager
2. Aset Presentasi dalam TLD
3. Layanan Repository

29
32
52

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).

Gambar 1 Area penerapan Software Reuse (Sommerville 2007)

2

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.
Direktorat Integrasi Data dan Sistem Informasi (DIDSI) sebagai unit yang
memiliki tugas dan pokok pengembangan sistem informasi merancang arsitektur
layanan sistem informasi di IPB seperti Gambar 2. Angka pada setiap lapisan
arsitektur pada Gambar 2 merupakan urutan prioritas yang akan dikerjakan oleh
DIDSI.

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
SIMPEG
DUPAK
Kinerja Pegawai
KGB
Payroll
Absen Online

Bahasa
Pemrograman
PHP
ASP .NET
Java EE
Java EE
PHP
PHP

Platform
DBMD

Web Server

SQL Server
SQL Server
SQL Server
SQL Server
SQL Server
SQL Server

Apache
IIS
Apache Tomcat
Apache Tomcat
Apache
Apache

4

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. Tools dan teknologi dalam implementasi bersifat homogen platform.

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.

Gambar 4 Layered architecure (Enterprise Layer) pada DDD (Evans 2004)

6

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 Impedance Mismatch (Paradigm Mismatch)
Perangkat lunak administrasi sangat erat kaitannya dengan penyimpanan
data ke basisdata. Sampai saat ini basisdata yang paling sering digunakan masih
berbasis Relational Database Management System (RDBMS) dimana terdiri dari

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
Granularity

Subtype (inheritance)

Objek
Terdiri
Berbagai
tingkatan
granularity,
dalam satu tabel dapat
terdiri dari beberapa kelas
objek
Terdapat
mekanisme
inheritance

Identity

Identitas menggunakan
Identity, equality

Asscociation

Referensi
dapat
dilakukan
secara
Directional
Mengakses data dari satu
relasi ke relasi lain dapat
menggunakan atribut dari
objek

Data navigation

Relasi
Terdiri dari dua level
granularity tabel dan
kolom
Tidak
terdapat
mekanisme
terhadap
inheritance
Identitas
(Sameness)
menggunakan
primary
key
Referensi menggunakan
Foriegn key dan tidak
directional
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
untuk sistem Java dimulai pada tahun 2002 dan saat ini ORM juga telah
diimplementasikan pada Microsoft pada sistem .Net dengan nama Entity Data
Model (EDM) (MSDN 2015). ORM dapat mengakomodir Object-Relational
Impedance Mismatch agar dapat menggunakan RDBMS.

8

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)

Scope

Class
Object

Creational
Factory Method
Abstract Factory
Builder
Prototype
Singleton

Purpose
Structural
Behavioral
Adapter
Interpreter Template Method
Adapter
Chain of Responsibility
Bridge
Command
Composite
Iterator
Decorator
Mediator
Facade
Memento
Flyweight
Observer
Proxy
State
Strategy
Visitor

Design pattern yang dikembangan oleh Gamma et al. (1994) sangat
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
- Dapat digunakan bersama-sama untuk memecahkan masalah yang lebih besar

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

Kode Program

JDBC

DBMS

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.

Gambar 6 Mekanisme tradisonal untuk melakukan akses ke DBMS

Kode Program

DAO

DBMS

10

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

uses

encapsulates

DataSource

creates/uses
ValueObject

obtains/modifies

Gambar 8 DAO Pattern (Deepak et al. 2001)

BussinessObject

DataAccessObject

DataSource

1:Create
2:GetData

2.1:GetData
2.2:Create

2.3:Return Object

ValueObject

3:Set Property
4:Set Property
5:Set Data

5.1:Get Propery
5.2:Get Property
5.3:Get Property

Gambar 9 DAO Sequence Diagram (Deepak et al. 2001)

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.
Perancangan
Mekanisme Arsitektur

Pemilihan Teknologi
dan Tools

Domain
Masalah
Lainnya

Analasis Domain
Kepegawaian

Domain

Presentation

Implementasi
Repository
Pengujian

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
ini didapat dari beberapa sumber yang berkaitan dengan aturan kepegawaian
seperti: Undang-Undang Republik Indonesia Nomor 5 Tahun 2014 Tentang
Apatur Sipil Negara (UURI No 5 2014), UU yang berkaitan dengan PNS pada
Perguruan Tinggi, SK Rektor yang berkaitan dengan kepegawaian, Form Isian
Pegawai Negeri dari BKN (Badan Kepegawaian Negara), Struktur Organisasi IPB,
data dan aplikasi web sudah ada sebelumnya dan hal aktivitas lainnya yang
berkaitan dengan permasalahan kepegawaian. Model konseptual yang dihasilkan
dari analisis domain yang akan digunakan sebagai ValueObject pada DAO.

12

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
dengan domain.

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.
Implementasi Aset
Domain

Presentasi

Proyek DAO

Proyek Domain

Proyek Presentasi

Utilitas

Pustaka Domain

Pustaka Antarmuka

Pustaka Utilitas

Infrastructure Layer
Pustaka DAO

Source Code Management
Dokumentasi
Repository

Application Layer

Pengembangan Aplikasi Web

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
IDE

Tools

Akses Data
Manajemen
Proyek

Produk
Digunakan untuk
Eclipse Java EE
Pengembangan aset
Hibernate
ORM,
Pemetaan Model Konseptual ke basis data
Hibernate Tools
Maven

Project Builder, Library Depedency

14

Tabel 5 Lanjutan Teknologi dan Tools java yang digunakan
Tools
Repository

Produk

Digunakan untuk
Kontrol
terhadap
public
library,
Artifactory, Git-scm
manajemen pustaka, penyimpanan kode
(GitBlit),
Custom
sumber, dokumentasi kode program dan
Web Tutorial
tutorial penggunaan

Front-end
framework

Boostrap, Jquery

Digunakan sebagai antarmuka

MVC

Struts2, Freemarker

User Interface Component,
Design, Application Layer

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
BKN (Badan Kepegawaian Negara)
.

Gambar 12 Model Konseptual Pegawai
15

16

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.

Gambar 14 Model Konseptual Gaji

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.

Gambar 16 Model Konseptual Penugasan

18

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
parameter. Kelas ini bersifat generik sehingga dapat diwarisi oleh DAO yang
lebih spesifik untuk menangani proses bisnis tertentu.

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
2

https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/associations.html
https://docs.jboss.org/hibernate/orm/3.5/reference/en/html/inheritance.html#inheritance-strategies

20

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 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
Dao
pegawai-model

Depedency
Pustaka hibernate
dao-versi.jar

domainpermasala dao-versi.jar
han-model

Hasil proyek
dao-versi.jar, Dokumentasi
Pegawai-model-versi.jar,
Dokumentasi
model
domain
pegawai
domainpermasalahan-modelversi.jar, Dokumentasi

Proyek Presentasi
Implementasi aset antarmuka (presentation) dilakukan seperti pada Gambar
20 dalam sebuah proyek presentasi. Diimplementasikan menggunakan konsep

21

template dan theme pada Struts MVC (Model View Controller) Component 3 .
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

Referensi
desain

Kostumisasi template

Digunakan
untuk desain

mapping
Komponen antarmuka
menggunakan Komponen
antarmuka Struts

atribut
Referensi
TLD

Atribut
desain

Front-end
framework

Mapping

Tag, Parameter
JSP

hasil

Controller

Akses data

Gambar 20 Implementasi Proyek Presentation
Proyek presentasi menghasilkan pustaka antarmuka dengan nama uiversion.jar. Untuk menggunakan pustaka setiap response yang ditampilkan dalam
bentuk JSP (Java Servlet Pages) mendefinisikan baris kode yang merujuk ke TLD
(). 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

https://struts.apache.org/maven/struts2-core/apidocs/org/apache/struts2/components/packagesummary.html
3

22

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

Gambar 24 Persentasi live-search dan upload

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
dihasilkan pada penelitian ini dilampirkan pada Lampiran 3.

24

depedency
create

Maven
Project

build

Organization
Library

IDE

Java Doc
Tools

generate

API/
Documentation

library version

fetch
Reuse
Reuse Architect
Architect
commit

Git-scm

IDE
Web
Web Developer
Developer

Local
Local Repository
Repository

Public
Public Maven
Maven Repository
Repository

Web
Web Server
Server

commit

fetch

create

Maven Web
App Project

dependency

deploy

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.

Gambar 27 Aplikasi web SIMPEG

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 pi