SISFO-Jurnal Sistem Informasi

1

DESIGN PATTERN UNTUK PEMBANGUNAN SERVICE PADA KERANGKA KERJA BERBASIS SERVICE ORIENTED

ARCHITECTURE : OHIS

Radityo Prasetianto W1), Daniel Oranova Siahaan2), Fajar Baskoro3) 1,2,3Jurusan Teknik Informatika

Gedung Teknik Informatika Kampus ITS Sukolilo, Surabaya 60111

E-mail : radityo_pw@is.its.ac.id1), daniel@if.its.ac.id2),fajarbaskoro@gmail.com3)

Abstrak

OHIS (Organic Health Information System) merupakan kerangka kerja berbasis service oriented architecture (SOA) yang dapat digunakan untuk membangun sistem informasi berbasis service dengan model pengembangan per modul sehingga dapat dengan mudah untuk dikembangkan. Berdasarkan hasil penelitian tentang OHIS, kemudian dilakukan penelitian – penelitian lain terkait dengan pembangunan layanan pada kerangka kerja tersebut seperti layanan manajemen, layanan rawat inap serta layanan apotek di mana ketiga layanan tersebut melakukan pembangunan layanan yang terintegrasi dengan kerangka kerja OHIS.

Namun, semua percobaan pembangunan layanan yang telah dilakukan terjebak pada paradigma pemrograman berbasis procedural yang sama sekali tidak sesuai dengan desain yang dituliskan dan sangat sulit untuk dilakukan pengujian terutama secara independen. Salah satu penyebabnya adalah sulitnya memodelkan hubungan antara sistem dengan basis data secara berorientasi objek sehingga service yang dibangun akan dituntun dari desain basis data.

Penelitian ini akan memberikan pandangan bagaimana memodelkan service berorientasi objek yang akan memfokuskan pada eksplorasi design pattern yang berfokus pada hubungan sistem dengan basis data relasional yang digunakan sehingga diharapkan layanan yang dibangun tidak terjebak pada pengembangan secara prosedural.

Keywords: kerangka kerja, design pattern, unit of work, unit testing, table data gateway

1. PENDAHULUAN

Rumah Sakit memainkan peranan penting dalam memberikan layanan kesehatan yang baik pada masyarakat. Teknologi Informasi dan Komunikasi merupakan hal yang esensial dalam memberikan data dan informasi yang akurat kepada para stakeholder pelayanan kesehatan. Menurut LeRounge, Mantzana dan Vance Wilson (2007), teknologi informasi tidak bisa digunakan hanya sebagai faktor pendukung. Menurut mereka, pembangunan infrastruktur teknologi informasi layanan kesehatan yang terintegrasi, meningkatkan layanan, dan menurunkan kegagalan medis menjadi kebutuhan strategik bagi penyedia layanan kesehatan. Penelitian mengenai OHIS (Organic Health Information System) Framework (Mahananto F dkk, 2009) merupakan penelitian pendahuluan yang mengarahkan kepada pembangunan kerangka kerja berbasis arsitektur berorientasi layanan yang dapat digunakan untuk membangun sistem informasi layanan dengan model pengembangan per modul sehingga dapat

dikembangkan dengan mudah. Penelitian tersebut lantas dilanjutkan dengan penelitian – penelitian lain terkait dengan pembangunan layanan pada kerangka kerja tersebut seperti layanan manajemen (Wibisono G.T dkk, 2009) , layanan rawat inap (Kemastuti E dkk, 2009) serta layanan apotek (Nugroho A.A dkk, 2009). Ketiga layanan tersebut melakukan pembangunan layananan yang terintegrasi dengan kerangka kerja OHIS. Namun, semua percobaan pembangunan layanan yang telah dilakukan terjebak pada paradigma pemrograman berbasis prosedural yang sama sekali tidak sesuai dengan desain yang dituliskan (menggunakan UML). Selain itu juga sangat sulit untuk dilakukan pengujian terutama pengujian secara independen. Untuk melakukan pembangunan service berorientasi objek dapat dilakukan dengan beberapa cara misalnya dengan membuat CASE (Computer Aided Software Engineering) yang mengotomasi proses desain dengan penghasilan kerangka kode yang berbasis objek. Cara lain yang dapat ditempuh (dan menjadi pelengkap

2

cara pertama) adalah dengan melengkapi kerangka kerja OHIS dengan perangkat pustaka yang mampu membantu memodelkan layanan secara objek terutama yang berkaitan dengan hubungan kerangka kerja OHIS dengan sistem basis data yang digunakan. Penelitian ini berfokus pada implementasi design pattern yang berhubungan dengan basis data relasional. Hal ini membuat pengembangan layanan tidak lagi terjebak pada paradigma prosedural berorientasi basis data yang menyulitkan pengujian secara terpisah seperti pada tiga percobaan pembuatan layanan sebelumnya. 2. KERANGKA KERJA OHIS

2.1 Konsep Dasar

OHIS dibangun atas dasar perbaikan projek SIRST dengan mengadopsi konsep SOA (Binildas, 2008). Ide dasarnya adalah membuat kerangka kerja yang memiliki 2 area berbeda, (1) area main yang berisi minimum requirement dari semua rumah sakit secara umum dan layanan – layanan yang bersifat mandatory; (2) area layanan yang berisi predefined classses yang berguna dalam pembangunan layanan, dan berisi layanan itu sendiri pula.

Gambar 1 desain dasar dari kerangka kerja OHIS

Pada gambar 1 (Desain dasar OHIS), diperlihatkan model dasar arsitektur OHIS dimana terdapat 2 bagian utama, yaitu bagian Main dan bagian layanan yang pada gambar di atas adalah pharmacy, out-patient dan in-patient. Tujuan dari desain ini adalah membuat sebuah kerangka kerja yang mudah untuk tumbuh dan berkembang, memiliki kemudahan dalam melakukan proses mix and match diantara subsistem–subsistemnya. Mudah untuk tumbuh dan berkembang adalah kemudahan untuk menambahkan subsistem baru (layanan baru) dan kemudahan pula untuk

menguranginya. Sedangkan kemudahan melakukan proses mix and match berarti kesemua layanan dapat saling berhubungan dan bertukar informasi yang bertujuan untuk menyelesaikan task dari masing–masing layanan itu sendiri. Hal yang utama pada desain arsitektur yang digunakan pada kerangka kerja ini adalah penggunaan webservice berbasis SOAP sebagai komponen kunci. Hal ini tergambar pada hubungan antara client dan server yang menggunakan protokol https pada gambar 2. Secara umum flow yang terjadi adalah menggunakan model yang menjadikan client sebagai producer dan main sebagai consumer dari layanan, atau dapat dilihat bahwa main sebagai koordinator sekaligus consumer dari layanan – layanan yang ada. Semua layanan yang ada pada sistem akan dibentuk dan dibangun menjadi semakin banyak. Hal ini membutuhkan sebuah tempat penyimpanan data untuk mendaftar semua layanan, sehingga main akan mudah menemukan dan melakukan listing layanan yang ada pada sistem. Main akan melakukan listing dari fungsi–fungsi layanan tersebut dan memberikan pilihan pada pengguna untuk memilih fungsi apa yang ingin dijalankan oleh pengguna.

Gambar 2 Arsitektur Kerangka Kerja OHIS

Template parser akan melakukan pengubahan pada template yang ada pada sistem template dengan data yang didapatkan dari proses webservice. Template ini akan melihat tipe dari data yang akan ditampilkan, dapat berupa tipe grid, atau tipe–tipe lainnya, sehingga programmer hanya perlu mendefininsikan tipe dan memberikan data pada layanan yang

SISFO-Jurnal Sistem Informasi

3

dibuatnya. Hal ini diharapkan dapat membantu dalam proses pembuatan layanan. Metode ini sebenarnya diadopsi dari paradigma naked objek yang merupakan kerangka kerja berbasis objek murni (Pawson R, Matthews R, 2002), hanya saja pendekatan naked objek itu berfokus pada pengembangan tampilan per objek yang dibangun, sedangkan template parser pada kerangka kerja OHIS lebih akan seperti widget pada layanan. 2.2 Pemetaan Kebutuhan Fungsional Menjadi Sebuah Layanan

Untuk membangun OHIS, terlebih dahulu dilakukan kajian mendalam mengenai apa saja yang dibutuhkan oleh rumah sakit untuk membentuk sebuah solusi sistem informasi yang diinginkan. Kerangka kerja OHIS membagi bagian kerja dalam dua bagian yaitu main dan services, dimana main berisi fungsi–fungsi umum yang ada pada rumah sakit atau bisa disebut fungsi minimum pada rumah sakit. Penelitian tentang penentuan kebutuhan fungsional minimum yang ada pada beberapa rumah sakit tipe C telah dilakukan oleh Afandi dkk (2009). Hasil dari penelitian tersebut merupakan rekomendasi untuk membentuk area kerja main. Pada penelitian tersebut disebutkan pelayanan rumah sakit terdiri atas :

1. Pelayanan Medik Pelayanan medik adalah pelayanan terhadap pasien yang dilaksanakan oleh tenaga medis. Pelayanan rawat inap, rawat jalan dan gawat darurat termasuk dalam layanan ini.

2. Pelayanan Penunjang Medik Pelayanan penunjang medik adalah pelayanan untuk penunjang penegakan diagnosis dan terapi. Contohnya seperti laboratorium, radiologi, farmasi dan kamar operasi.

3. Pelayanan Penunjang Non Medik Pelayanan penunjang non medis adalah pelayanan yang diberikan di Rumah Sakit yang secara tidak langsung berkaitan dengan pelayanan medik. Contohya seperti administrasi umum. Berdasarkan hasil dari penelitian tersebut, fitur–fitur umum yang ada pada setiap rumah sakit adalah: administrator, keuangan, logistik dan penunjang medis. Fitur–fitur tersebut akan masuk ke dalam area kerja main, dan fitur–fitur selain itu akan masuk area services. Hal tersebut dapat dilihat pada gambar 3, dimana fitur layanan medis bukan merupakan fitur umum yang ada di main. Dalam penelitian tersebut dikatakan pula bahwa dalam sebuah sistem informasi rumah sakit, paling tidak terdapat 3 buah struktur utama yang

membagi komponen dalam sistem informasi rumah sakit, yaitu: (1) Modul, (2) Fitur, (3) Fungsi. Dimana setiap Fitur akan memiliki banyak Modul dan Setiap Modul akan memiliki banyak Fungsi. Namun dalam kerangka kerja OHIS menggunakan pendekatan layanan dalam pembuatan sistem informasinya sehingga perlu dilakukan proses pemetaan antara terminology fungsi yang ada pada keadaan rumah sakit nyata dengan aspek teknis pada pemrograman layanan pada kerangka kerja OHIS. Pada gambar 4 dapat dilihat proses pemetaan fungsionalitas rumah sakit kedalam service pada kerangka kerja OHIS. Dikarenakan kerangka kerja OHIS menggunakan pendekatan berbasis objek pada tingkatan teknisnya, maka sebuah modul pada sistem informasi rumah sakit akan dianalogikan dengan class pada kerangka kerja OHIS. Dalam sebuah modul akan terdapat banyak function, kemudian function tersebut akan dipetakan menjadi method dalam kerangka kerja OHIS. Dalam hal ini, ada fitur yang tidak dapat dipetakan secara langsung dikarenakan fitur merupakan kumpulan dari banyak modul.

Gambar 3 fitur minimum kerangka kerja OHIS

Untuk mengatasainya, kerangka kerja OHIS melakukan pendekatan khusus dimana pemetaan fitur dilakukan pada unit khusus yaitu register yang tujuannya mendaftarkan / menggrupkan method – method dalam class untuk masuk ke dalam sebuah fitur atau lebih. Unit register ini akan mendaftarkan grup tersebut pada basis data yang digunakan kerangka kerja OHIS. Pada umumnya hal ini dilakukan pada method _up() , dimana method _up() hanya akan dipanggil 1 kali saja pada saat instalasi sebuah service.

4

Gambar 4 pemetaan fungsional kerangka kerja OHIS

Kode layanan yang merupakan layanan dari kerangka kerja OHIS dapat berupa kode dari banyak bahasa atau dengan kata lain tidak bergantung pada bahasa pemrograman tertentu. Penelitian ini fokus untuk meneliti kode dalam bahasa pemrograman PHP, dikarenakan container (service server) milik kerangka kerja OHIS yang telah terbentuk sampai tulisan ini dibuat adalah yang berbasis PHP. 2.3 Standar Kode Service

Skeleton kode layanan OHIS yang ditunjukkan pada gambar 5 merupakan skeleton kode layanan dalam bahasa PHP. Dari gambar tersebut terdapat beberapa bagian yang dapat disimpulkan dalam point-point berikut :

1. Tag pembuka <?php yang menandakan bahwa dokumen ini merupakan dokumen PHP.

2. Pembuatan class Layanan_name (layanan) harus mengextends Class lain yaitu ModuleClass, dengan kata lain layanan merupakan turunan dari class ModuleClass.

3. Konstruktor harus memiliki parameter inputan yaitu $key, $key merupakan metode autentikasi yang menjamin bahwa layanan ini diakses oleh server main atau layanan lain yang memang berhak.

4. Method _up() merupakan method khusus dimana hanya dipanggil saat layanan ini diinstall ke dalam server layanan, biasanya isinya mengenai pembuatan tabel – tabel yang dibutuhkan oleh layanan.

5. Method _down() merupkan method khusus dimana hanya dipanggil saat layanan ini dihapus dari server layanan, biasanya isinya mengenai penghapusan tabel yang sudah tidak dipakai.

6. Method function1($data) merupakan method buatan pengembang dari layanan yang harus memiliki parameter input $data yang berupa asosiative array yang berisi data request dari server main atau layanan lain.

7. Method function1_response($data) merupakan method buatan pengembang yang opsional jika terdapat method function1($data) yang membutuhkan penanganan lebih lanjut.

Bagian paling akhir adalah comment mengenai nama file yang sama dengan nama layanan serta lokasi di layanan server dimana layanan ini diinstall. Penutup tag PHP tidak diperlukan karena untuk menghindari error, mengingat bahwa semua layanan tidak memiliki kode lain selain PHP (misal : HTML yang biasanya terjadi pada programmer pemula PHP). Hal lain yang bisa menjadi informasi tambahan adalah, kemampuan OOP pada PHP untuk layanan tersedia seperti OOP pada umumnya, artinya semua method yang bertipe public akan dapat dipanggil oleh server main atau layanan lainnya. Sehingga jika para pengembang layanan ingin membuat method yang bersifat eksklusif hanya untuk kebutuhan layanannya sendiri maka dapat membuat methods yang bertipe private.

Gambar 5 skeleton kode layanan berbasis PHP

3. DESIGN PATTERN PADA PEMBANGU-NAN SERVICE 3.1 Proses Desain Pembangunan Service Proses desain pembuatan service seperti pada gambar 6 dimulai dari pembuatan diagram use case yang isinya mengenai cerminan kebutuhan dari pengguna. Diagram tersebut akan mempengaruhi pembuatan diagram sequence (digambarkan dengan garis putus–putus) yang menggambarkan hubungan antara class–class yang ada untuk mencapai kebutuhan pengguna. Setelah diagram sequence dibuat maka didapatkanlah daftar class beserta behaviour pada class tersebut yang direpresentasikan dalam bentuk method. Class–class tersebut digabungkan dalam sebuah diagram class yang merupakan daftar semua class yang ada pada sistem. Setelah membuat diagram class maka langkah selanjutnya adalah menentukan class apa yang membutuhkan media penyimpanan persistent (menggunakan

SISFO-Jurnal Sistem Informasi

5

sistem basis data relasional) yang nantinya akan diolah lebih lanjut pada bagian database design. Pada diagram class ini juga dibuat class–class yang belum didefinisikan pada diagram sequence jika memang diperlukan. Untuk setiap class pada diagram class yang membutuhkan media penyimpanan basis data, maka akan dibentuk pula tabel pada database design yang memiliki kolom berdasarkan attribute dalam class yang bersangkutan. 3.2 Main Class Pada Service Prinsip kerja main class adalah bagaikan kumpulan fungsi utama (main function) yang bertujuan untuk menjalankan sistem atau perangkat lunak yang dibuatnya. Bukan berarti main class digunakan untuk melakukan semua perintah pemrograman dalam perangkat lunak, namun hanya sebagai pengaktif dari class–class yang lain untuk bekerja. Pemrograman langsung pada fungsi utama memang menyalahi aturan dasar dari pemrograman beriorientasi objek dan merupakan praktek buruk yang dapat mengakibatkan para pengembang perangkat lunak berfikir prosedural (Pawson R, Matthews R, 2002). Selain itu, pemrograman langsung pada fungsi utama dapat mengakibatkan sulitnya perangkat lunak untuk dilakukan pengujian, dikarenakan tidak terpisahnya modul pengembangan yang digunakan. Hal ini akan berbeda sangat jauh jika menggunakan paradigma pemrograman berbasis objek karena masing – masing objek akan dengan mudah dilakukan pengujian. 3.3 Pemetaan entity class ke dalam tabel dalam basis data Desain fisik dari tabel dalam sistem basis data akan mengikuti kebutuhan pada desain class yang memang membutuhkan media penyimpanan permanen pada sistem basis data. Martin Fowler (2002) pada bukunya menjelaskan beberapa langkah dalam melakukan pemetaan dari sebuah class menjadi tabel dalam sistem basis data. Pada dasarnya, pemetaan yang dilakukan cukup mudah yaitu memetakan satu buah class dengan satu buah tabel. Langkah selanjutnya adalah dengan menambahkan kolom tambahan yang utama yaitu kolom “id” sebagai kolom kunci utama (primary key) pada tabel tersebut. Pada gambar 7 dapat dilihat bahwa penambahan kolom “id” pada class dapat mempermudah pada saat pembuatan tabel yaitu sebagai kunci utama pada tabel dalam sistem basis data. Kolom “id” bisa juga dikombinasikan dengan sistem penomoran

otomatis, karena kolom “id” bertipe integer sehingga hal tersebut dimungkinkan.

Gambar 6 proses desain layanan

Pada sistem basis data relasional, kekuatan utamanya adalah beberapa tabel dapat saling berelasi atau berhubungan. Hubungan tersebut diatur dalam sebuah constraint yang disebut foreign key. Pemetaan foreign key dalam class dapat dilihat pada asosiasi antar class. Asosiasi pada class akan menunjukkan jumlah ketergantungan dari masing – masing class tersebut. Pada kasus ketergantungan one to many maka ketergantungan tersebut juga berdampak pada tabel yang dihasilkan seperti pada gambar 8.

Gambar 7 Pemetaan class ke dalam tabel

Asosiasi pada class juga dapat berdampak pada pembuatan tabel baru jika class yang terasosiasi memiliki keterhubungan many to many, sehingga dibutuhkan sebuah tabel tambahan yang mencatat hubungan tersebut. Pada gambar 9 dapat dilihat contoh pemetaan asosiasi dari class ke dalam tabel baru. Tabel baru tersebut dibutuhkan untuk pemetaan asosiasi yang bersifat many to many . Pada gambar tersebut diperlihatkan hubungan antara pasien dan penyakit dimana satu orang pasien bisa memiliki 1 atau lebih penyakit, dan satu buah penyakit bisa di miliki satu atau lebih pasien.

6

Gambar 8 contoh pemetaan foreign key

Gambar 9 pemetaan asosiasi class pada tabel 3.4 Hubungan Data Dengan Tabel pada entity class Untuk mengatasi masalah hubungan antara data dengan tabel pada entity class digunakan pattern Table Data Gateway. Pattern ini bertujuan sebagai jembatan antara class dengan sistem basis data relasi yang digunakan untuk menyimpan informasi dari class tersebut. Dengan adanya teknik seperti ini diharapkan pemisahan antara objek dan SQL sebagai perintah untuk sistem basis data akan tertata lebih baik.

Gambar 10 Table Data Gateway Pattern Pada gambar 10 dapat dilihat sebuah Table Data Gateway yang disebut PersonGateway akan memiliki method yang dapat mengakses tabel Person. Class PersonGateway sangat bergantung dengan class Person, artinya jika terjadi perubahan pada class Person maka kemungkinan besar juga akan terjadi perubahan pada class PersonGateway. Nantinya setiap entity class akan melakukan delegasi kepada Table Data Gateway pada tabel yang diinginkan sehingga data akan dimiliki oleh entity class. Data yang ada dalam basis data akan berada dalam memori sehingga akan berdampak pada kecepatan akses dari data tersebut. Namun hal lain yang dapat terjadi adalah dampak dari sulitnya mengingat bahwa perubahan yang terjadi pada entity class haruslah terjadi pula pada sistem basis data,

sehingga membutuhkan sebuah sistem yang mengatur, menampung, mengeksekusi dan membatalkan semua proses transaksi perubahan dari entity class. 3.5 Pencatatan Proses Perubahan Data pada entity class

Ketika menarik data yang masuk dan keluar dari database seperti yang dilakukan entity class, penting untuk melacak apa yang telah berubah pada entity class, karena data tidak secara otomatis ditulis kembali ke database, demikian pula pada proses memasukkan maupun menghapus data pada entity class. Hal ini akan diselesaikan dengan mengimplementasikan pattern unit of work. Umumnya tanpa menggunakan unit of work, setiap perubahan data pada entity class langsung akan disimpan ke dalam basis data, hal ini termasuk strategi yang aman dalam proses perubahan data pada entity class. Namun, hal ini akan dapat mengakibatkan sering terjadinya proses pembukaan koneksi - query - penutupan koneksi ke dalam sistem basis data, sehingga sistem menjadi lambat.

Gambar 11 Unit Of Work

Pattern UnitOfWork akan bekerja untuk mencatat objek entity apa yang berubah, dan perubahan akan dicatat dalam dua bentuk perubahan yaitu dalam bentuk dirty dan dalam bentuk remove yang masing–masing akan mencatat perlunya entity untuk diupdate atau dihapus dalam basis data seperti pada gambar 11. Unit of Work juga diimplementasikan dengan pattern singleton untuk memastikan bahwa unit of work hanya ada satu buah objek saja. Pattern singleton termasuk dalam kategori Creational Pattern yang tujuan utamanya adalah memastikan bahwa sebuah objek hanya dibuat satu kali saja dan memberikan akses secara global terhadap objek tersebut. Dalam banyak kasus, memiliki satu buah class (benar–benar satu buah) sangat penting, mungkin saja sebuah komputer dihubungkan dengan dua atau lebih printer, namun, printer spooler tetaplah harus satu buah, memiliki satu buah window manager.

SISFO-Jurnal Sistem Informasi

7

Masalah ini sebenarnya terselesaikan dengan menggunakan metode variabel global dalam teknik pemrograman yang berorientasi fungsional atau prosedural. Namun hal ini bukanlah teknik yang tepat dalam pemrograman berbasis objek sehingga diperlukan teknik khusus dalam mengatasi permasalahan ini. Solusinya adalah memberikan kekuasaan penuh terhadap class dalam melakukan pembuatan objeknya (instansiasi) dan memberikan objek tersebut kepada variabel global yang dapat diakses class manapun.

Gambar 12 contoh singleton pattern

Seperti yang terlihat pada gambar 12 dimana class Singleton memiliki atribut private bertipe Singleton yang bertujuan memegang objek yang dibuat pada saat memanggil constructor yang bertipe private. Dikarenakan constructor bertipe private maka pemanggilan tersebut (pembuatan objek) hanya boleh dilakukan oleh class itu sendiri, yakni dengan memanggilnya dari method init():Singleton, dimana method tersebut akan melakukan pengecekan terlebih dahulu dari variabel instance, jika belum bernilai objek Singleton (belum terbentuk objek tersebut) maka dibuatlah objek Singleton dan diberikan kepada variabel instance, lalu method init():Singleton akan mengembalikan variabel instance.

Gambar 13 proses unit of work bekerja dengan entity

(Pasien) Unit of Work akan bekerja sangat erat dengan objek dari Entity dimana seperti pada gambar 13, objek Entity yang digambarkan sebagai Pasien dapat dirubah oleh objek manapun dan tanpa melakukan hubungan langsung dengan basis data yang ada. Setiap terjadi proses

perubahan data, Pasien tidak serta merta menuliskannya ke dalam basis data. Jika pada saatnya nanti , proses pengupdetan data pada basis data akan dipicu oleh dipanggilnya method commit pada UnitOfWork, yang nantinya akan memanggil objek Entity yang berhubungan dan memaksanya untuk mengupdate data yang dimilikinya ke dalam basis data. 3.6 Testing Class

Dengan menerapkan paradigma pemrograman berbasis objek pada pembangunan service pada kerangka kerja OHIS, mengakibatkan kemudahan bagi para pengembang untuk melakukan pengujian pada class – class yang mereka buat. Hal ini dikarenakan pengembangan yang dilakukan menggunakan modularisasi yang baik pada masing–masing bagiannya. Teknik pengujian yang dapat dilakukan adalah unit testing berbasis class–class yang dibuat oleh pengembang seperti yang terlihat pada gambar 6. Setiap class yang dibuat oleh pengembang selain front class akan dibuat class pengujiannya masing–masing sesuai dengan teknologi bahasa pemrograman yang digunakan. 4. UJI COBA

Sumber data yang digunakan adalah use case yang diadaptasi dari dokumen SKPL (Spesifikasi Kebutuhan Perangkat Lunak) SIRST (Sistem Informasi Rumah Sakit Terpadu) versi 2 (Nisafani A.S, Fithroni A, 2009). Service yang akan dibangun untuk keperluan uji coba adalah service rekam medik, dimana terdapat service lain yang dengan asumsi telah terinstall sebelumnya adalah service pasien. Fungsi yang akan difokuskan untuk dibuat adalah fungsi “ambil_tindakan_ medis” dan “tambah_tindakan_medis”. sebagai pembanding digunakan kode service dari service IRNA secara procedural (Kemastuti E dkk, 2009). 4.1 Melihat Daftar Tindakan Medis

Bagian pada melihat daftar tindakan medis bertujuan untuk mendapatkan apa saja tindakan medis yang pernah dilakukan kepada seorang pasien. Gambar 13 merupakan cuplikan kode service yang bertujuan mendapatkan daftar tindakan medis yang pernah dilakukan, kunci utama ada pada baris ke 4 sampai 6 yang merupakan query langsung ke dalam sistem basis data.

8

Gambar 13 Contoh Cuplikan Kode Service Tidak OOP

Berbeda pada pendekatan sebelumnya, kode service pada gambar 14 menggunakan teknik OOP dengan lebih baik, pada baris ke 4, 5 dan 13 kode ini melakukan pembuatan class pasien yang akan dilihat tindakan medis apa saja yang pernah dilakukan kepadanya.

Gambar 14 Contoh cuplikan kode service OOP

Kode service ini membutuhkan class–class yang lain seperti Pasien. Class tersebut dapat dilihat pada gambar 15 dimana terdapat class Pasien dan TindakanMedis yang merupakan turunan dari class Entity. Dengan merupakan turunan class Entity maka kedua class tersebut dapat melakukan penyimpanan dan pengambilan data dari sistem basis data.

Gambar 15 Class lain yang dibutuhkan pada service

rekammedis Untuk keperluan pengujian, masing – masing class Pasien dan TindakanMedis akan dibangun juga class PasienTestCase dan TindakanMedis TestCase yang keduanya merupakan turunan dari class OhisTestCase. Dengan ini kode service akan lebih mudah untuk dilakukan pengujian karena telah terkelompokkan kedalam entitas unit terkecil yaitu class. 4.2 Menambah Tindakan Medis

Tindakan medis dapat ditambahkan pada pasien dalam rekam medis mereka. Dengan cara

procedural, dapat dilihat pada gambar 16 pada baris 4 dimana data langsung dimasukkan ke dalam sistem basis data, relasi yang digunakan dalam tabel harus dimasukkan secara explisit dalam query tersebut.

Gambar 16 Tambah Tindakan Medis Tidak OOP

Dengan menggunakan query sebenarnya para pengembang service akan bekerja dengan dua bahasa yang berbeda yaitu bahasa pemrograman dari kode service dan bahasa relasi dari sistem basis data. Hal tersebut akan berdampak minimal pada dua hal, yang pertama adalah tingkat kemudahan kode untuk dibaca yang lebih rumit karena menggunakan dua bahasa dan yang kedua adalah tingkat portabilitas dari service.

Gambar 17 Tambah Tindakan Medis OOP

Pada gambar 17 pendekatan yang lebih OOP diperlihatkan pada baris 4 sampai 10 adalah proses pemasukkan data tindakan medis yang baru terhadap seorang pasien. Hal ini dapat dilakukan dengan cara membuat objek pasien terlebih dahulu dengan id yang tepat, lalu membuat objek tindakan medis yang baru. Setelah kedua objek siap, maka langkah selanjutnya adalah merekatkan kedua objek tersebut. Objek UnitOfWork akan melakukan penulisan tahap akhir pada objek–objek yang berubah yang akan dituliskan ke dalam sistem basis data secara permanen. 5. KESIMPULAN

Dari paparan di atas, dapat dilihat bahwa desain kode service pada kerangka kerja OHIS dapat dilakukan dengan paradigma berorientasi objek, sehingga kode yang dihasilkan tidak terjebak pada paradigma procedural yang berfokus pada aplikasi berbasis basis data. Hal ini akan memudahkan pengujian secara terpisah atau independen. Kunci utamanya adalah prinsip pada main class yang tidak dijadikan tempat berkumpulnya semua kode, melainkan tempat untuk memanggil class–class lain yang

SISFO-Jurnal Sistem Informasi

9

dibutuhkan, persis seperti fungsi main function pada bahasa pemrograman berbasis objek. Dengan memanfaatkan design pattern yang berhubungan dalam memodelkan hubungan antara kode service dengan sistem basis data relasional, maka akan didapatkan kode service yang lebih mudah dibaca (tidak menggunakan dua bahasa) dan lebih memiliki tingkat portabilitas yang lebih tinggi dibandingkan yang tidak memanfaatkan design pattern tersebut. 5. DAFTAR PUSTAKA

Afandi M.Y , Ali A.H.N, Wahyu E.T (2009), Spesifikasi Kebutuhan Minimum Fungsional Sistem Informasi Rumah Sakit, Final Project Report, Jurusan Sistem Informasi ITS Binildas C.A, Barai M, CASElli V, “ Service Oriented Architecture with Java”, PACKT Publishing, Birmingham - Mumbai, 2008 Fowler M, Rice D , Foemmel M , Hieatt E , Mee R , Stafford R (2002), Patterns of Enterprise Application Architecture, Addison Wesley Kemastuti E, Ali A.H.N, Mahananto F (2009), PEMBANGUNAN MODUL RAWAT INAP (IRNA) DAN PENGINTEGRASIAN DALAM PURWARUPA SISTEM INFORMASI RUMAH SAKIT TERPADU (SIRST) BERBASIS SOA , Jurusan Sistem Informasi, ITS

LeRouge, C., Mantzana, V. dan Wilson, E.V. (2007) Healthcare information Systems research, revelations and visions. Mahananto F , Wibowo R.P, Ali A.H.N, Mahendrawathi Er, Igasaki T (2009), OHIS: SOA Based Grow-able Healthcare Information System Framework, the 10th Asia Pacific Industrial Engineering & Management Systems Conference (APIEMS) Kitakyushu Japan Nisafani A.S, Fithroni A (2009) Spesifikasi Kebutuhan Perangkat Lunak (SKPL) Sistem Informasi Rumah Sakit Terpadu (SIRST) Release 2, Jurusan Sistem Informasi, ITS Nugroho A.A, Ali A.H.N, Mahananto F (2009) PEMBANGUNAN MODUL APOTEK DAN PENGINTEGRASIAN DALAM PURWARUPA SISTEM INFORMASI RUMAH SAKIT TERPADU BERBASIS SOA, Jurusan Sistem Informasi, ITS Pawson R, Matthews R, 2002. Naked Object. England: John Wiley & Sons Ltd. Wibisono G.T, Ali A.H.N, Mahananto F (2009) PEMBANGUNAN MODUL MANAJEMEN DAN PENGINTEGRASIAN DALAM PURWARUPA SISTEM INFORMASI RUMAH SAKIT TERPADU BERBASIS SOA, Jurusan Sistem Informasi, ITS.