DESIGN PATTERN UNTUK PEMBANGUNAN SERVICE PADA KERANGKA KERJA BERBASIS SERVICE ORIENTED ARCHITECTURE : OHIS

SISFO-Jurnal Sistem Informasi

DESIGN PATTERN UNTUK PEMBANGUNAN SERVICE PADA KERANGKA KERJA BERBASIS SERVICE ORIENTED ARCHITECTURE : OHIS Radityo PW, S.Kom1), Daniel OS, P.D.Eng2) Fajar B, M.T3) 1,2,3 Jurusan Teknik Informatika Gedung Teknik Informatika Kampus ITS Sukolilo, Surabaya 60111 E-mail : [email protected]), [email protected]),[email protected])

Abstrak Telah ada penelitian yang mengarahkan kepada pembangunan kerangka kerja berbasis service oriented architecture (SOA) yang disebut OHIS yang dapat digunakan untuk membangun sistem informasi berbasis service dengan model pengembangan per modul yang dapat dengan mudah untuk dikembangkan. Penelitian tersebut lalu dilanjutkan dengan penelitian – penelitian lain terkait dengan pembangunan layanan pada kerangka kerja tersebut seperti layanan manajemen, layanan rawat inap serta layanan apotek yang ketiga layanan tersebut melakukan pembangunan layanan yang terintegrasi dengan kerangka kerja OHIS. Namun, dari semua percobaan pembangunan layanan yang telah dilakukan, semua 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 hal yang menyebabkan hal itu adalah karena sulitnya memodelkan hubungan antara sistem dengan basis data secara berorientasi objek sehingga menyebabkan service yangdibangun akan dituntun dari desain basis data. Paper ini akan memberikan pandangan bagaimana memodelkan service dengan 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 essensial dalam memberikan data dan informasi yang akurat kepada para stakeholder pelayanan kesehatan. Menurut LeRounge , Mantzana dan Vance Wilson (LeRounge dkk, 2007) , teknologi informasi tidak bisa digunakan hanya sebagai factor pendukung. Menurut mereka, pembangunan infrastruktur teknologi informasi layanan kesehatan yang terintegrasi , meningkatkan layanan dan menurunkan kegagalan medis menjadi kebutuhan strategik bagi penyedia layanan kesehatan. Telah ada penelitian yang mengarahkan kepada pembangunan kerangka kerja berbasis arsitektur berorientasi layanan yang disebut OHIS (Organic Health Information System) Framework (Mahananto F dkk, 2009) yang dapat digunakan untuk membangun sistem informasi layanan dengan model pengembangan

per modul yang dapat dengan mudah untuk dikembangkan. 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) yang ketiga layanan tersebut melakukan pembangunan layananan yang terintegrasi dengan kerangka kerja OHIS. Namun, dari semua percobaan pembangunan layanan yang telah dilakukan, semua terjebak pada paradigma pemrograman berbasis prosedural yang sama sekali tidak sesuai dengan desain yang dituliskan (menggunakan UML) dan sangat sulit untuk dilakukan pengujian terutama secara independen. Untuk melakukan pembangunan service berorientasi objek dapat dilakukan dengan beberapa cara misalnya dengan membuat CASE (Computer Aided Software Engineering) yang mengotomatiskan proses desain dengan

1


penghasilan kerangka kode yang berbasis objek. Cara lain yang dapat ditempuh (dan menjadi pelengkap 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.

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.

Paper ini berfokus pada implementasi design pattern yang berhubungan dengan basis data relasional, sehingga pengembangan layanan tidak lagi terjebak pada paradigma procedural berorientasi basis data sehingga akan sangat sulit untuk dilakukan pengujian secara terpisah seperti yang telah terjadi pada tiga percobaan pembuatan layanan sebelumnya.

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.

2. KERANGKA KERJA OHIS 2.1 Konsep Dasar OHIS dibangun atas dasar perbaikan projek SIRST dengan mengadopsi konsep SOA(Binildas, 2008). Dimana ide dasarnya adalah kerangka kerja 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 predifined classses yang berguna dalam pembangunan layanan, dan berisi layanan itu sendiri pula.

Semua layanan yang ada pada sistem akan dibentuk dan dibangun semakin banyak. Hal ini membutuhkan sebuah tempat penyimpanan data yang bertujuan melakukan list dari 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 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 layanans yang pada gambar di atas adalah pharmacy, out-patient dan inpatient. Tujuan dari desain ini adalah 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

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

2


grid, atau tipe – tipe lainnya, sehingga programmer hanya perlu mendefininsikan tipe dan memberikan data pada layanan yang dibuatnya. Maka hal ini sangat diharapkan dapat membantu dalam proses pembuatan layanan. Hal 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 Menjadi Sebuah Layanan

Fungsional

Untuk membentuk 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 bias disebut fungsi minimum pada rumah sakit. Untuk itu penelitian telah dilakukan dalam hal mencari kebutuhan fungsional minimum yang ada pada beberapa rumah sakit tipe c yang ditulis oleh afandi (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. Dari penelitian tersebut didapatkan bahwa fitur – fitur yang umum yang ada pada setiap rumah sakit adalah : administrator, keuangan, logistik dan penunjang medis. Maka fitur – fitur tersebut akan masuk ke dalam area kerja main, dan selain fitur – fitur tersebut akan masuk area services. Hal tersebut dapat dilihat pada gambar 3, dimana fitur layanan medis merupakan bukan fitur umum yang ada di main.

Dari 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, maka function tersebut akan dipetakan menjadi method dalam kerangka kerja OHIS. Hanya fitur yang tidak dapat dipetakan secara langsung dalam hal ini, dikarenakan fitur merupakan kumpulan dari banyak modul.

Gambar 3 fitur minimum kerangka kerja OHIS

Sehingga dalam hal ini kerangka kerja OHIS melakukan pendekatan khusus dimana pemetaan fitur dilakukan pada unit khusus yaitu register yang tujuannya mendaftarkan / menggrupkan method – method dalam class untuk kedalam 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.

3


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, namun dalam penelitian ini yang detiliti berfokus pada kode dalam bahasa pemrograman PHP, dikarenakan container (service server) yang telah terbentuk yang dimiliki kerangka kerja OHIS sampai tulisan ini dibuat adalah yang berbasis PHP. 2.3 Standar Kode Service Pada gambar 5 mengenai skeleton kode layanan OHIS, merupakan skeleton kode layanan dalam bahasa PHP. Dari gambar tersebut dapat dilihat beberapa bagian yang dapat disimpulkan dalam beberpa point berikut : 1. Tag pembuka
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 layanans server dimana layanan ini diinstall. Tidak dibutuhkannya penutup tag PHP dikarenakan agar 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 jadi tambahan informasi 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 menginginkan 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 PEMBANGUNAN SERVICE

PADA

3.1 Proses Desain Pembangunan Service Proses desain pembuatan service seperti pada gambar 6 dimulai dari pembuatan diagram use case yang berisikan mengenai cerminan kebutuhan dari pengguna. Diagram tersebut akan mempengaruhi pembuatan diagram sequence (digambarkan dengan garis putus – putus) yang akan menggambarkan hubungan antara class – class yang ada untuk mencapai kebutuhan pengguna. Setelah diagram sequence telah dibuat maka didapatkanlah daftar class

4

SISFO-Jurnal Sistem Informasi 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 sistem basis data relasional) yang nantinya akan diolah lebih pada bagian database design.

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 maksud dari penambahan kolom “id” pada class yaitu untuk mempermudah pada saat pembuatan tabel yaitu sebagai kunci utama pada tabel yang biasanya pada sistem basis data yang terkini bisa juga dikombinasikan dengan sistem penomoran otomatis, karena kolom “id” bertipe integer sehingga hal tersebut dimungkinkan.

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 penyimpabab 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 yang 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. Oleh martin fowler pada bukunya (Fowler M,dkk, 2002) dijelaskan beberapa langkah dalam melakukan pemetaan dari sebuah class menjadi tabel dalam sistem basis data. Secara dasar , pemetaan yang dilakukan cukup mudah yaitu memetakan satu buah class dengan satu

Gambar 6 proses desain layanan

Pada sistem basis data berbasis relasional, kekuatan utama adalah dapatnya beberapa tabel saling berelasi atau berhubungan. Hubungan tersebut diatur dalam sebuah constaint yang disebut foreign key. Pemetaan ke dalam foreign key ini di dalam class dilihat pada asosiasi pada antar class. Asosiasi pada class akan dilihat 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

5


pasien dan penyakit dimana satu orang pasien bisa memiliki 1 atau lebih penyakit, dan satu buah penyakit bisa di miliki satu atau lebih pasien.

dan hal ini 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

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 dimana dapat dilihat sebuah Table Data Gateway yang disebut PersonGateway akan memiliki method yang dapat mengakses tabel Person. Class PersonGateway akan sangat bergantung dengan class Person, artinya jika perubahan terjadi pada class Person maka kemungkinan besar akan terjadi juga 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. Sehingga data yang ada di dalam basis data akan berada di dalam memori

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 berefek pada manjadi lambatnya sistem.

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 didalam basis data seperti pada gambar 11. Unit of Work juga diimplementasikan dengan pattern singleton, dimana memastikan 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

6

SISFO-Jurnal Sistem Informasi lebih printer, namun, printer spooler tetaplah harus satu buah, memiliki satu buah window manager. 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.

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 bangiannya. Teknik pengujian yang dapat dilakukan adalah unit testing dimana unit testing yang dibuat akan berbasiskan 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 ujicoba 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

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

Bagian pada melihat daftar tindakan medis bertujuan untuk mendapatkan apa saja tindakan medis yang pernah dilakukan kepada seorang pasien. Pada gambar 13 merupakan cuplikan kode service yang bertujuan mendapatkan daftar

7


tindakan medis yang pernah dilakukan, kunci utama ada pada barus ke 4 sampai 6 yang merupakan query langsung ke dalam sistem basis data.

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 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 16 Tambah Tindakan Medis Tidak OOP

Dengan menggunakan query sebenarnya para pengembang service akan bekerja dengan dua buah 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 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 TindakanMedisTestCase yang keduanya merupakan turunan dari class OhisTestCase. Dengan ini kode service akan lebih mudah untuk dilakukan pengujian dikarenakan telah

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 mendesain kode service pada kerangka kerja OHIS dapat dilakukan dengan paradigma berorientasi objek, sehingga kode yang

8


dihasilkan tidak terjebak pada paradigma procedural yang mana berfokus pada aplikasi berbasis basis data. Sehingga akan mudah untuk dilakukan 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 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

9


3

DESIGN PATTERN UNTUK PEMBANGUNAN SERVICE PADA KERANGKA KERJA BERBASIS SERVICE ORIENTED ARCHITECTURE : OHIS

Recommend Documents