6
HASIL DAN PEMBAHASAN Analisis Permasalahan Ketidaksesuaian Untuk mendapatkan gambaran yang lebih lengkap terhadap Ritel ERP (Ernita, 2008) yang akan dianalis, berikut ini diuraikan deskripsi umum ERP untuk perusahan Ritel tersebut. 1 Deskripsi Umum Aplikasi Ritel ERP Sistem ERP Ritel yang dikembangkan Ernita (2008) terdiri atas tiga mudul, antara lain: Modul pembelian (Business to Business) Purchase Requisition (PR) yang dikirim oleh kepala gudang kepada pihak pengadaan barang. Request for Quotation (RFQ) dan Purchase Order (PO) yang dikirim oleh bagian pengadaan kepada supplier. Demand Order (DO) yang dikirim oleh supplier kepada bagian pengadaan barang. Goods Receive yang diperiksa oleh kepala gudang saat barang diterima. Manajemen Inventory. Daftar supplier. Modul Penjualan (Business-to-Customer) Daftar katalog yang ditampilkan kepada pelanggan. Submodul pemesanan (add to cart) Konfirmasi tagihan dan pembayaran. Pengantaran barang. Daftar pelanggan. Modul akuntansi Jurnal buku besar (General Ledger) Konfirmasi tagihan dan pembayaran. Account Receivable (AR) Account Payable (AP) Manajemen kode akun. Masing-masing modul pembangun Ritel ERP tergabung pada satu basis data yang terpusat. 2 Analisis Masalah Ketidaksesuaian Aplikasi Ritel ERP membutuhkan basis data dalam menjalankan proses bisnisnya. Tiga modul utama pembangun aplikasi Ritel ERP mengakses pada satu basis data yang terpusat. Setiap modul mempunyai tabel master untuk inisialisasi data dari lingkungan proses bisnis aplikasi Ritel ERP dan tabel transaksi sebagai hasil transaksi saat menjalankan proses bisnisnya. Tabel master dan tabel transaksi yang dirancang
untuk membangun aplikasi Ritel ERP dapat dilihat pada Lampiran 1. Pada penelitian ini, aplikasi Ritel ERP dikembangkan dengan pendekatan berorientasi objek menggunakan bahasa pemrograman Java, sedangkan sistem manajemen basis data yang digunakan adalah basis data relasional. Oleh karena itu, terdapat ketidaksesuaian (mismatch) yang ditimbulkan pada perbedaan konsep tersebut. Pada penelitian ini, tidak semua aspek ketidaksesuaian ditemukan. Aspek ketidaksesuaian yang muncul adalah aspek granularity, identitas, asosiasi antarentitas, dan navigasi data. Uraian berikut memaparkan analisis ketidaksesuaian pada aspek: a Granularity Ketidaksesuaian pada aspek granularity terjadi karena pada basis data relasional tidak mengenal user-defined-data-type atau tipe data yang didefinisikan oleh pengguna. Ketidaksesuaian aspek granularity yang ditemukan pada penelitian ini terjadi saat mendefinisikan properti address pada entitas Supplier. atribut Address terdiri atas street, town, state, zip_code. Aribut address akan dipisahkan menjadi class berbeda saat pembuatan DTO, akan tetapi setelah dipetakan tetap masuk sebagai proserti tabel PU_SUPPLIER. b Identitas Ketidaksesuaian pada aspek identitas terkait dengan perbedaan pengenal identitas objek dan tabel. Pada objek identitas dibedakan menjadi nilai dan alamat memorinya. Oleh karena itu, terdapat dua notasi yang melambangkan kesamaan suatu identitas, yaitu lambang sama dengan (==) dan method equals(). Sebagai contoh (a == b), berarti variabel a dan b memegang alamat reference yang sama pada memori, sedangkan (a.equals(b)), secara lojik mempunyai nilai yang sama. Pada basis data relasional, identitas dari suatu tabel disebut dengan primary key. Dengan demikian, sering kali terjadi objek yang secara lojik sama (a.equals(b)) dan mewakili satu baris dalam tabel basis data, tetapi objek tersebut tidak berada pada satu lokasi alamat memori yang sama.
7
c Asosiasi
1 Melakukan Konfigurasi Basis Data
Kebanyakan entitas pada basis data mempunyai keterhubungan dengan entitas yang lainnya. Elemen yang menghubungkan kedua tabel tersebut ditandai dengan foreign key.
Tahap konfigurasi merupakan tahap awal sebelum melakukan akses terhadap basis data. Konfigurasi basis data disimpan pada file jdbc.properties. Isi dari file jdbc.properties adalah sebagai berikut:
Elemen penghubung dua objek ditandai dengan sebuah reference object. Permasalahannya adalah reference object bergantung pada arah dari asosiasinya (direction of relationship). Apabila asosiasi antara dua objek terjadi pada dua arah, maka harus didefinisikan dua kali pada setiap classnya. Akan tetapi foreign key pada tabel relasional tidak mengenal arah dari asosiasinya, karena asosiasi antara dua tabel dihubungkan dengan tabel join.
1 2 3 4 5 6 7 8 9 10
Ketidaksesuaian pada aspek asosiasi meliputi relasi one-to-one, one-to-many, dan many-to-many. Masing-masing asosiasi antarentitas bisa dilihat pada class diagram dan ER diagram pada Lampiran 2 dan Lampiran 3. d Navigasi data Ketidaksesuaian pada aspek navigasi terkait dengan masalah bagaimana mengakses suatu objek yang berasal dari objek lain. Menurut arahnya, navigasi data terbagi menjadi dua macam, yaitu: unidirectional dan bidirectional. Pada konsep pemrograman berorientasi objek konsep arah navigas menentukan suatu objek dapat diakses melalui objek lain, sedangkan pada basis data relasional konsep arah navigasi tidak mempengaruhi proses pengaksesan data dari tabel lain. Pada konsep pemrograman berorientasi objek, proses akses properti objek dari objek lain bisa langsung menggunakan method getter. Lain halnya dengan basis data relasional, properti yang menjadi penghubung antara dua tabel yang berelasi yaitu foreign key. Perancangan dan Implementasi ORM dan Design Pattern Setelah ditemukan empat aspek ketidaksesuaian tersebut diimplementasikan ORM. Selain itu juga diterapkan design pattern untuk menghilangkan ketidaksesuaian yang muncul pada tahap analisis tersebut, meliputi:
jdbc.username=root jdbc.password=admin jdbc.url=jdbc:mysql://localhost: 3306/erp jdbc.driver=com.mysql.jdbc.Driver hibernate.dialect=org.hibernate. dialect.MySQL5InnoDBDialect hibernate.show_sql=true hibernate.hbm2ddl.auto=create hibernate.format_sql=true
Baris pertama sampai ke lima merupakan properti konfigurasi koneksi basis data yang berisi username, password, host dan port basis data, dan library koneksi yang digunakan. Kode pada baris ke enam menentukan jenis dialek SQL yang akan dipetakan. Baris ke delapan adalah properti untuk menampilkan hasil query yang telah diubah ke dalam bentuk SQL. Baris ke sembilan merupakan properti yang berfungsi mengotomasi pembuatan basis data dari awal sampai akhir. Dan baris ke sepuluh untuk menghasilkan query dengan format SQL. 2 Membuat Class DTO (Data Transfer Object) DTO merupakan class yang merepresentasikan setiap tabel pada basis data. DTO dibuat berdasarkan UML class diagram yang telah dirancang. DTO berisi class JavaBean yang setiap propertinya akan merepresentasikan atribut-atribut pada tabel. Skema proses pembuatan DTO diilustrasikan pada Gambar 4.
8
Product -id : int -prodName : string -unitPrice : double
public class private private private //getter and }
Product{ int id; String prodName; Double unitPrice; setter method
product PK
id : int prod_name : varchar unit_price : longint
Prod_ID
Prod_name
Unit price
1
pupuk
100
2
bibit
200
Gambar 4 Skema Pembuatan DTO. Ketidaksesuaian yang muncul pada tahap analisis diatasi oleh ORM pada saat merepresentasikan class DTO dan diakses sebagai objek. Uraian berikut menjelaskan implementasi konsep ORM untuk mengatasi ketidaksesuaian pada aspek granularity, identitas, asosiasi, dan navigasi data. a Aspek Granularity Proses pemetaan untuk memecah entitas menjadi entitas yang lebih kompleks pada atribut address dalam entitas Supplier menjadi satu entitas address ditulis sebagai berikut:
- Class Supplier 1 2 3 4 5 6 7
@Entity @Table(name = "PU_SUPLIER") public class Supplier{ @Embedded private Address address = new Address(); }
-
Class Address
1 2 3 4 5 6
@Embeddable public class Address { private String street; private String city; private String zipCode; }
Properti @Embeddable pada baris pertama class Address mengindikasikan
bahwa class Address merupakan entitas yang bisa dilekatkan atau dimasukan ke dalam entitas lain. Properti @Embedded di baris ke lima pada class Supplier menandakan bahwa entitas Address melekat pada entitas Supplier. b Aspek Identitas ORM mengatasi ketidaksesuaian pada aspek identitas dengan menambah properti identity pada setiap entitas atau class DTO seperti pada potongan program berikut: 1 2 3 4 5 6 7 8 9
@Entity @Table(name = "IN_ITEM") public class Item{ @Id @GeneratedValue(strategy= GenerationType.AUTO) @Column(name="id") private Long id; }
Kode pada baris pertama dan kedua menandakan bahwa class tersebut mewakili sebuah entitas pada basis data dengan nama tabel IN_ITEM. @Id pada baris ke empat merupakan properti yang merepresentasikan primary key, secara lojik properti @Id pada class a berbeda dengan @Id pada class b. Dengan demikian pengujian apakah isi class a sama dengan class b bisa ditulis seperti berikut: a.getid().equals(b.getId()). Properti @GeneratedValue (strategy = GenerationType.AUTO merupakan pengisian id yang secara otomasi seperti auto_increment pada tabel relasional.
c Aspek Asosiasi Asosiasi antara dua entitas terdiri atas one-to-one, one-to-many, dan many-tomany. Proses pemetaan asosiasi antara dua entitas adalah sebagai berikut: One-to-one
Gambar 5 Pemetaan Asosiasi one-to-one.
9
Gambar 5 merupakan ilustrasi dari class
One-to-many
Demand yang berasosiasi one-to-one dengan class Order. Letak foreign key atau join column ditambahkan pada entitas yang
mempunyai total participation pada asosiasi yang menghubungkannya. Pada entitas yang mempunyai asosiasi dua arah (bidirectional) diperlukan penambahan properti mappedBy oleh entitas yang tidak total participation (entitas partial participation), sedangkan pada entitas yang mempunyai asosiasi satu arah (unidirectional) tidak perlu menambahkan properti mappedBy. Proses pemetaan dua class Demand dan class Order merupakan contoh asosiasi dua arah (association bidirectional) dan class Demand bersifat total participation. Pemetaan class Demand dan class Order dapat dituliskan sebagai berikut: -
Class Order
1 2 3 4 5 6
@Entity @Table(name="pu_order") public class Order { @OneToOne (mappedBy="order") private Demand demand; }
-
Class Demand
1 2 3 4 5 6 7
@Entity @Table(name="pu_demand") public class Demand { @OneToOne @JoinColumn (name="id_order") private Order order; }
Properti Join Column dimasukan pada class Demand karena entitas Demand mempunyai total participation. Dengan demikian, objek Demand menentukan asosiasi antara dua entitas tersebut. Asosiasi one-to-one di atas disebut biderectional karena masing-masing class memerlukan reference yang menghubungkannya. Baris empat dan baris enam pada class Demand menandakan suatu reference yang mewakili foreign key dari entitas Order. Begitu pula pada class Order, reference yang menghubungkannya ditulis dengan mappedBy yang dituliskan pada baris ke empat dan lima. Properti mappedBy=”order” pada class Order merujuk pada nama atribut order pada class Demand.
Gambar 6 Pemetaan Asosiasi one-to-many. Gambar 6 merupakan ilustrasi class yang berasosiasi one-tomany dengan class RequisitionDetail. Jadi setiap satu objek Requisition terdiri atas banyak objek RequisitionDetail.
Requisition
Seperti halnya asosiasi one-to-one, asosiasi one-to-many mempunyai join column yang disimpan pada entitas yang mempunyai total participation. Akan tetapi pada asosiasi one-to-many, entitas yang mempunyai total participation pasti berada pada entitas yang berkardinalitas many. Dengan demikian, dapat dikatakan join column berada pada entitas dengan kardinalitas many. Class Requisition berasosiasi one-tomany dengan class RequisitionDetail. Apabila asosiasinya bidirectional, maka dapat dikatakan class RequisitionDetail berasosiasi many-toone dengan class Requisition. Proses pemetaannya ditulis sebagai berikut:
- Class RequisitionDetail 1 2 3 4 5 6 7
@Entity @Table (name="pu_req_detail") Public class RequisitionDetail { @ManyToOne @JoinColumn (name="id_req") private Requisition requisition; }
-
Class Requisition
1 2 3 4 5 6 7 8 9
@Entity @Table(name="pu_req") public class Requisition{ @OneToMany(mappedBy = "requisition") private List
reqDetail = new ArrayList (); }
Asosiasi many-to-one di atas bersifat biderectional, sehingga properti join
10
column
berada pada entitas yang berkardinalitas many yaitu class RequisitionDetail. Akan tetapi pada entitas yang berkardinalitas one ditambahkan properti mappedBy sebagai reference.
Properti asosiasi dan reference dalam class RequisitionDetail ditulis pada baris empat dan baris lima. Pada class PurchaseRequisition, reference yang menghubungkannya ditulis dengan mappedBy seperti pada baris empat sampai baris delepan. Apabila asosiasinya unidirectional, properti mappedBy pada class Requisition dihilangkan. Properti mappedBy = “requisition” merujuk kepada atribut “requisition” pada class RequisitionDetail. Many to many
-
Class Group
1 2 3 4 5 6 7 8 9
@Entity @Table(name = "ad_group") public class Group { @ManyToMany(mappedBy= "groups") private List <Modul> moduls = new ArrayList <Modul>(); }
- Class Modul 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
@Entity @Table(name="ad_modul") public class Modul { @ManyToMany @JoinTable (name = "ad_modul_group", joinColumns={ @JoinColumn(name= "id_ad_modul")}, inverseJoinColumns={ @JoinColumn(name= "id_ad_group")}) private List groups = new ArrayList < Group>(); }
Peoperti Join table dimasukan pada properti yang mempunyai total participation yaitu class Modul. Objek Modul menentukan asosiasi pada kedua entitas tersebut. Gambar 7 Pemetaan Asosiasi many-to-many. Gambar 7 merupakan ilusrasi class Group berasosiasi many-to-many dengan class Modul. Kedua entitas yang berasosiasi
many-to-many dihubungkan oleh reference berupa join tabel. Join tabel memiliki dua buah atribut foreign key yang berasal dari masing-masing entitas. Atribut join tabel dimasukan pada entitas yang memilki total participation pada asosiasi tersebut. Properti mappedBy ditambahkan kepada entitas partial participation apabila asosiasinya dua arah (bidirectional), sedangkan pada entitas yang mempunyai asosiasi satu arah (unidirectional) tidak perlu menambahkan properti mappedBy. Proses pemetaan asosiasi di atas merupakan asosiasi dua arah (association bidirectional) dan entitas Modul mempunyai total participation. Pemetaan class Group dan class Modul dituliskan seperti berikut:
Asosiasi many-to-many di atas bersifat biderectional karena masing-masing class memerlukan reference yang menghubungkannya. Properti many-to-many pada class Modul ditulis pada baris empat. Kemudian reference yang menghubungkannya berupa join table yang terdiri atas identity dari masing-masing entitas. Properti join table ditulis pada baris lima sampai empat belas dalam class Modul. Dalam class Group, reference yang menghubungkannya ditulis pada baris empat sampai baris delapan. Properti mappedBy=”groups” pada class Group merujuk pada nama atribut groups pada class Modul. Hasil pemetaan dari asosiasi many-tomany antara dua class tersebut adalah dua tabel hasil transformasi dari objek yaitu AD_MODUL dan AD_GROUP kemudian satu tabel asosiasi AD_MODUL_GROUP. d Aspek Navigasi data Pada konsep pemrograman berorientasi objek, proses akses properti objek dari objek
11
lain bisa langsung menggunakan method getter. Contoh:
- Class Item 1 2 3 4 5 6 7
@Entity @Table(name = "IN_ITEM") public class Item { @ManyToOne @JoinColumn(name="id_brand") private Brand brand; }
Class Item mempunyai variabel brand dengan tipe data Brand seperti ditulis pada baris ke enam. Untuk mengakses nilai brand dengan tipe data Brand pada class Item menggunakan method getter seperti berikut: invItem.getInvProdBrand.getName();
Apabila arah navigasinya unidirectional, maka tidak terdapat properti entitas Item pada class Brand, sehingga class Brand tidak bisa mengakses properti entitas Item. Tetapi apabila arah navigasinya bidirectional, maka pada class Brand terdapat properti entitas Item seperti berikut: -
Class Brand
1 2 3 4 5 6
@Entity public class Brand { @OneToMany(mappedBy="brand") private List - item = new ArrayList
- (); }
Properti mappedBy pada baris ke tiga menandakan bahwa class tersebut mempunyai asosiasi bidirectional. Untuk mengakses variabel item dengan tipe data Item dari class Brand menggunakan method getter seperti berikut: invProdBrand.getInItem.getName();
Basis data relasional tidak mengenal konsep arah navigasi dalam mengakses data. Properti yang menjadi penghubung antara dua tabel yang berelasi yatiu foreign key. Tabel ITEM dan BRAND mempunyai relasi one-to-many kemudian foreign key berada pada tabel ITEM. Selama ada foreign key yang menghubungkan kedua tabel, proses query yang melibatkan kedua tabel bisa dijalankan. Query berikut merupakan query untuk mengakses properti item dengan berdasarkan id_brand pada tabel ITEM.
Select * from IN_ITEM i left outer join IN_PROD_BRAND pb on i.id=pb.id where i.id=123
Properti left outer join menandakan bahwa foreign key berada pada tabel ITEM. 3 Membuat Fungsi Akses Data Pada penelitian ini, DAO pattern digunakan untuk proses enkapsulasi fungsi untuk mengakses data ke dalam lapisan yang berbeda, sehingga aplikasi tidak perlu mengetahui detail proses suatu data diakses. DAO berisi method (fungsi) untuk mengakses dan memanipulasi data. Pada penerapannya, DAO dapat diimplementasikan dengan native query atau bahasa query basis data relasional (Structure Query language). DAO juga dapat diimplementasikan dengan konsep ORM dengan menggunakan HQL (Hibernate Query Language). Proses pembuatan fungsi-fungsi akses dan manipulasi data memanfaatkan konsep design pattern, yaitu factory method dan singleton. Sebelum melakukan akses dan manipulasi data, terlebih dulu dibuat objek dataSource yang berisi referensi dari properti koneksi basis data. DataSource memanggil referensi properti koneksi basis data yang ada pada file konfigurasi jdbc.properties, antara lain: username, password, server dan port, nama url basis data, dan jenis driver RDBMS. Objek dataSource dan semua objek DAO hanya diinstansiasi satu kali selama aplikasi berjalan. Objek dataSource dimasukan ke setiap DAO ketika DAO diinstansiasi, sehingga proses koneksi basis data tidak dilakukan secara berulang-ulang melainkan cukup dipanggil apabila diperlukan. Framework ORM yang digunakan untuk proses pengaksesan data pada penelitian ini adalah Hibernate. DAO diimplementasikan menggunakan HQL (Hibernate Query Language). DAO berisi method untuk mengakses dan memanipulasi data seperti create, update, delete, insert, select, dan join. Pada penelitian ini, proses pembuatan objek dataSource dan proses memasukan dataSource ke dalam semua DAO dilakukan menggunakan Spring Framework dengan teknik Inversion of Control (IoC). Teknik IoC dalam pembuatan objek
12
dataSource dapat dilihat pada Lampiran 5.
Selain objek dataSource, objek yang diperlukan untuk mengakses data menggunakan ORM adalah objek sessionFactory. Seperti halnya objek dataSource, objek sessionFactory bersifat singleton, jadi objeknya hanya dibuat sekali sepanjang aplikasi berjalan. Objek sessionFactory dipanggil oleh setiap class DAO yang mengakses basis data. membuat objek SessionFactory session yang diperlukan untuk proses transaksi yang berlangsung saat mengakses data. Session merupakan objek yang hanya sekali pakai, digunakan untuk melakukan transaksi basis data dan setelah selesai transaksi, session langsung ditutup. Siklus hidup objek session berbeda dengan objek sessionFactory, sessionFactory dibuat sekali sepanjang aplikasi berjalan, sedangkan session dibuat selama proses suatu transaksi berlangsung. Session bertanggungjawab selama proses transaksi, session tidak bisa ditutup sebelum transaksi berhasil dan session akan melakukan rollback apabila transaksi gagal. Pada penelitian ini, proses pembuatan sessionFactory dan proses memasukan objek sessionFactory ke dalam semua
DAO dilakukan menggunakan Spring framework dengan teknik Inversion of Control (IoC) seperti halnya pada pembuatan dan penggunaan dataSource. Teknik IoC untuk sessionFactory dapat dilihat pada Lampiran 5. session dibuat oleh class HibernateDaoSupport melalui method getHibernateTemplate. Method getHibernateTemplate bertujuan
Objek
membersihkan lapisan aplikasi dari kode pengaksesan data yang berulang-ulang. Method getHibernateTemplate membuat kode program untuk penyimpanan objek ke dalam basis data menjadi sebagai berikut: public class CartDaoHibernate extends HibernateDaoSupport{ public void save(Cart cart) { getHibernateTemplate().saveOr Update(cart); } }
Kode program untuk pengambilan objek dari basis data ditulis sebagai berikut: Mengambil objek cart sesuai dengan id tertentu public Cart getById(Long cartId) { Cart cart = (Cart) getHibernateTemplate(). load(Cart. class, cartId); getHibernateTemplate().initialize (cart); return cart; }
Mengambil objek cart berdasarkan status yang sedang aktif. Public Cart getByStatus (String status){ Cart cart = (Cart) getHibernate Template.find(“from Cart c where c.status=?”, “active”); return cart; }
Mengambil objek detailCart berdasarkan cart tertentu. Public DetailCart getByCart (Cart Cart){ DetailCart detailCart = (Detail Cart) getHibernateTemplate.find(“from CartDetail cd left join fetch cd.cart”); return detailCart; }
Mengambil semua objek cart. public List getAll() { return getHibernateTemplate(). find("from Cart"); }
Kode program untuk menghapus objek cart: public void delete(Cart cart) { getHibernateTemplate().delete (cart); }
4 Penyederhanaan Fungsi Akses Data Aplikasi Ritel ERP pada penelitian ini terdiri atas 50 class DTO yang masingmasing mempunyai interface DAO untuk akses dan manipulasi data seperti insert, select, atau delete. Agar mudah diakses, semua DAO dikumpulkan berdasarkan submodul ERP ke dalam interface Service. Interface Service merupakan implementasi dari facade pattern, yaitu menyederhanakan fungsi-fungsi yang terlihat rumit dengan mengelompokkan fungsi-fungsi tersebut ke dalam beberapa interface sehingga menghasilkan fungsi yang lebih sederhana dan mudah digunakan. Proses penyederhanaan 50 class DTO menghasilkan tujuh interface Service,
13
lain AccountPayableService, AccountReceivableService, Admin GeneralLedgerService, Service, InventoryService, OrderService, dan PurchaseService. Proses memasukan DAO ke dalam Service menggunakan antara
5 Membuat Skema Basis Data.
teknik Inversion of Control oleh Spring Framework. Teknik IoC untuk Service dapat dilihat pada Lampiran 6.
Properti <prop key = "hibernate. hbm2ddl.auto"> ${hibernate. hbm2ddl.auto} adalah property untuk membuat skema basis data. Variabel ${hibernate.hbm2ddl.auto} merujuk pada properti hibernate.hbm2ddl.auto pada file jdbc.properties. nilai variabelnya adalah create. Ada beberapa
Implementasi dari semua DAO pada Service dituliskan sebagai berikut: public class OrderServiceImpl implements OrderService { DebiturDao orderDebiturDao; CartDao orderCartDao; }
Objek Service adalah properti yang akan diakses oleh lapisan aplikasi dalam proses pengaksesan basis data. Akan tetapi, sebelumnya dilakukan teknik Declarative Transaction terhadap Service dengan menerapkan konsep proxy pattern, yaitu pola yang merancang suatu objek mewakili kontrol atau akses objek lain bertindak seolah-olah objek tersebut melakukannya Declarative Transaction merupakan suatu teknik untuk medeklarasikan semua transaksi dalam suatu file konfigurasi untuk menangani semua proses transaksi tanpa harus membuat kode-kode program untuk menangani transaksi secara eksplisit. Proses Declarative Transaction ditulis pada file hibernate.ctx.xml. Proses Declarative Transaction dimulai dengan mengatur transaksi oleh objek session. Objek session yang digunakan saat transaksi dikendalikan oleh class proxy yang dihasilkan melalui teknik Declarative Transaction. Ketika lapisan aplikasi memanggil Service untuk mengakses basis data, method Service tidak mengakses basis data secara langsung. Akan tetapi Service memanggil moduleXXXService pada file hibernate.ctx.xml untuk membuat class proxy yang berisi fungsifungsi transaksi (begin, commit, rollback). Fungsi-fungsi transaksi tersebut dimasukan ke dalam Session melalui method getHibernateTemplate, sehingga tidak perlu menuliskan proses transaksi secara programatik mengendalikan Session, karena transaksi dilakukan secara deklaratif oleh class proxy melalui method getHibernateTemplate.
pilihan yang bisa digunakan untuk properti hbm2ddl.auto, yaitu create-drop artinya Hibernate akan membuat semua tabel pada saat inisialisasi sessionFactory. Begitu sessionFactory ditutup, semua tabel akan dihapus. Pilihan yang ke dua adalah create artinya pada saat sessionFactory dijalankan akan membuat semua tabel dan pada saat sessionFactory ditutup tabel yang dihasilkan tidak akan dihapus. Selain properti hbm2ddl.auto, yang digunakan pada proses pembuatan skema basis data adalah properti hibernate.show_sql. Properti hiberntae.show_sql akan menampilkan SQL yang digunakan saat query menggunakan HQL. Skema basis data yang dihasilkan digambarkan pada Lampiran 6. 6 Menyatukan Lapisan dengan Lapisan Aplikasi
Persistensi
Framework yang digunakan pada lapisan aplikasi dan presentasi adalah Java Server Faces (JSF). JSF adalah UI (User Interface) framework untuk aplikasi Java berbasis web dengan konsep MVC yang mendukung user interface berbasis komponen. Setiap action yang dilakukan memerlukan class controller atau backing bean. Pada class controller biasanya dilakukan proses pengaksesan terhadap basis data. Class controller yang akan mengakses atau memanipulasi data memanggil method Service sesuai data yang diperlukan. Misalnya jika diperlukan data Item, maka DAO yang berisi method untuk mengakses data Item disimpan pada ItemDao, kemudian ItemDao dimasukan ke dalam InventoryService. Oleh karena itu, untuk mengakses data Item dipanggil InventoryService. Dan terakhir mengatur konfigurasi controller untuk JSF pada file faces-config.xml. method Service yang digunakan oleh controller
14
dideklarasikan pada file konfigurasi facesconfig.xml. Contoh class controller yang mengakses data adalah seperti berikut: 1 2 3 4 5 6 7 8 9 10 11 12
public class InventoryController { private InventoryService inventoryService; private Item item; @PostConstruct public void initBean(){ } public String save(){ item.setStatus("active"); InventoryService.saveItem (item); return "success";} }
Method initBean pada baris lima dan enam yang dianotasi oleh @PostConstruct, artinya method ini dipanggil setelah constructor ListInvController dipanggil yang bertujuan inisialisasi data pada halaman tampilannya. Class Controller di atas bertugas untuk menyimpan objek item ke dalam basis data seperti dituliskan pada baris sepuluh Class Controller yang telah dibuat dideklarasikan pada file konfigurasi facesconfig.xml seperti berikut: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
<managed-bean> <managed-bean-name> InventoryController <managed-bean-class> ilkom.erp.web.controller. inventory.InventoryController <managed-bean-scope> Request <managed-property> <property-name inventoryService #{moduleInventoryService}
Baris ke tiga merupakan penulisan deklarasi nama controller yang akan dipanggil pada lapisan presentasi. Nama controller tersebut berisi class controller yang didefinisikan pada baris ke enam dan baris ke tujuh. Properti yang dipunyai controller tersebut didefinisikan pada baris ke 12 sampai baris ke 19.
Evaluasi Proses pemetaan menggunakan ORM dituliskan dengan kode sederhana, hal ini sangat membantu pihak pengembang dalam melakukan query data. ORM menghilangkan kode-kode exception dan native query yang terlihat berantakan dan tidak terstruktur. ORM mengabstraksi penggunakan Relational Data Base Management System (RDBMS), sehingga mendukung jenis RDBMS manapun. Query yang digunakan tidak menurut pada satu jenis RDBMS, melainkan menggunakan query language yang disediakan oleh ORM. Pemanfaatan konsep design pattern menghasilkan kode program yang lebih rapi dan terstruktur, serta memudahkan untuk proses integrasi antara lapisan basis data dan lapisan aplikasi. Dengan penerapan konsep design pattern, kode program aplikasi dapat dengan mudah dipelihara untuk pengembangan aplikasi selanjutnya. Perbedaan fungsi akses data tanpa menggunakan ORM, teknik Inversion of Controls, dan teknik Declarative Transaction, akses data menggunakan ORM tetapi tanpa penerapan teknik Inversion of Controls dan teknik Declarative Transaction, dan fungsi akses data menggunakan ORM, Inversion of Controls, dan teknik Declarative Transaction dapat dilihat pada Lampiran 7. Kekurangan dari konsep ORM yang diterapkan dalam pengembangan sistem ERP yaitu apabila terjadi perubahan, penambahan, dan pengurangan domain model harus meliputi seluruh aspek dari mulai pembuatan DTO, DAO, Service, dan deklarasi pada file konfigurasi.
KESIMPULAN DAN SARAN Kesimpulan Pada penelitian ini, tidak semua aspek ketidaksesuaian ditemukan. Aspek ketidaksesuaian yang muncul pada penelitian ini hanya meliputi empat aspek, yaitu aspek granularity, identitas, navigasi data, dan asosiasi antarentitas. Implementasi konsep ORM terbukti dapat menghilangkan ketidaksesuian yang muncul karena perbedaan antara aplikasi yang dibangun dengan pendekatan berorientasi objek dan basis data relasional yang digunakan.
