PEMBANGUNAN PURWARUPA COMPUTER AIDED SOFTWARE ENGINEERING TOOL UNTUK

PEMBUATAN LAYANAN PADA KERANGKA KERJA BERBASIS SERVICE ORIENTED ARCHITECTURE : OHIS

Radityo PW (5107201008)Thesis

PROGRAM MAGISTERBIDANG KEAHLIAN TEKNIK INFORMATIKA

JURUSAN TEKNIK INFORMATIKAFAKULTAS TEKNOLOGI INFORMASI

INSTITUT TEKNOLOGI SEPULUH NOPEMBER

Latar Belakang

1. Sambul Alwin (2009), Scientific Meeting : Toward The Implementation of SOA in Healtcare Information System; a review of current practice in healtcare information system in indonesia, PREDICT-ITS batch III

2. VIVANEWS,“1200 Rumah Sakit di Indonesia Masih Manual”, http://nasional. vivanews. com/news/ read/4359- 1200_rumah_ sakit_di_ indonesia_ masih_manual (09 Maret 2009).

3. LeRouge, C., Mantzana, V. dan Wilson, E.V. (2007) Healthcare information Systems research, revelations and visions. European Journal of Information Systems 16: 669–671.

Trend LayananKesehatanGeneral keSpesifik [1]

95% RumahSakit di

Indonesia masihmanual[2]

pembangunaninfrastruktur

teknologi informasikebutuhanstrategik[3]

OtomatisasidenganSistem

Informasi

Framework OHIS

Masalahpada

Framework OHIS

CASE Tool

KesesuaiandenganDesain

PenulisanAturan2DesainPada

coding

Tujuan

• membuat CASE Tool untuk Pembangunan Service pada Framework OHIS

• CASE Tool ini dapat mempermudah hal – hal yang masih rumit jika membangun service secara coding, yaitu :– desain layanan– desain basis data pada layanan– pemilihan model tampilan user– penggunaan layanan lain– registrasi layanan beserta fungsi dan aktivitasnya– instalasi layanan– penghapusan layanan (jika terjadi error pada saat testing)– testing dari layanan

Permasalahan

• Pembuatan CASE Tool ini dikhususkan pada framework OHIS sehingga permasalahan yang mucul adalah bagaimana mengintegrasikan CASE Tools ini dengan framework OHIS.

• Pembuatan CASE Tool ini terdiri dari pembuatan diagram – diagram seperti PDM, Use case, Class dan Sequence , permasalahannya adalah bagaimana cara mengintegrasikan semua diagram tersebut dan menghasilkan kode yang spesifik.

• Hal yang mengganggu pada pembangunan service dilingkungan framework OHIS adalah sulitnya melakukan testing pada servicedikarenakan sebuah service harus diinstal terlebih dahulu sebelum dilakukan testing. Sehingga bagaimana membangun sistem automatic testing pada saat service selesai dibangun dan sebelum dideploy.

Batasan Masalah

• Service dibangun dengan asumsi metodologi pengembangan perangkat lunak menggunakan metode waterfall.

• CASE Tool dibangun hanya dapat digunakan untuk pembangunan service pada aplikasi yang menggunakan framework OHIS, walaupun menggunakan metode – metode pemodelan yang umum seperti UML dan PDM.

• CASE Tool ini secara garis besar akan melakukan pemodelan Servicemenggunakan UML dan pemodelan Database (opsional) menggunakan PDM serta kemampuan melakukan instalasi dan penghapusan service secara langsung.

• CASE Tool dibangun menggunakan pemrograman Java.• Kode yang dihasilkan CASE Tool adalah kode berbasis PHP yang

menjadi service pada framework OHIS.• CASE Tool dibangun sebagai aplikasi standalone.

Kontribusi

• Kontribusi dari penelitian ini, adalah suatu CASE Tool yang menggunakan notasi grafis UML danPDM untuk desain dan pembangunan servicemenggunakan pola yang digunakan frameworkOHIS– Komponen Use Case Diagram– Komponen Sequence Diagram– Komponen Class Diagram– Komponen Generate Service Code– Komponen CodeEditor– Komponen Deploy dan Testing

Penelitian yang Lain

• Beberapa penelitian telah dilakukan untuk membangun CASE tools dalam kaitan untuk desain dan development sebuahaplikasi :– penelitian mengenai Framework yang juga membangun CASE tools

berbasiskan MDA [1][2].

– Penelitian itu membangun CASE tools untuk sebuah sistem dengan memanfaatkan atau menyediakan design pattern yang akan diimplementasikan dengan menggunakan PSL(pattern spesific language)[3]

– ArgoUML menggunakan model UML untuk mendesign kode dan dapat menghasilkan kode yang spesifik pada bahasa pemrograman yang dipilih[4]

1. George A. Komatsoulis (2007), caCORE version 3: Implementation of a model driven , service oriented architecture for semantic interoperability.

2. Harith T. Al-Jumaily , Dolores Cuadra, Paloma Martínez (2008), OCL2Trigger: Deriving active mechanisms for relational databases using Model-Driven Architecture, Elsevier Inc

3. Joan Peckham, Bonnie MacKellar (2001), Generating Code for Engineering design system using software patterns, Elsevier Science Ltd

4. ArgoUML, http://argouml.tigris.org (diakses oktober 2009)

Mengapa Masih Perlu CASE Tool lain untuk OHIS ?

Pendekatan ArgoUMLYang diinginkan (berbasisFramework OHIS)

Dokter.php Perawat.phpMelihat_jadwal_dokte

r.php

RawatInap.php

Fungsi melihat_jadwal_dokter($data)

Fungsi tersebut boleh diakses olehdokter dan perawat

Framework OHIS

model dasar arsitektur OHIS dimana terdapat 2 bagian utama, yaitubagian Main dan bagian services yang pada gambar di atas adalahpharmacy, out-patient dan in-patient.

Pemetaan Kebutuhan Fungsional => Service

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

Pemetaan Kebutuhan Fungsional => Service

Pemetaan Kebutuhan Fungsional => Service

• Untuk Memetakan Modul RekamMedis danfungsi Tambah kondisi pasien, maka padalayanan (service) akan dibuat :

Class RekamMedis extends ModuleClass{function _up(){}function _down(){}function tambah_kondisi_pasien($data = array()){}

}

Main Area

Client

Services

Data

Data

Services Loader

Services Requester

ServiceLocation List

1

23

4

4

5

6

6

7

Template Parser

8

9

Using HTTPS

Arsitektur Framework OHIS

Skeleton dari Service berbasis PHP

<?php

class Service_name extends ModuleClass{

public function __construct($key){

parent::__construct($key);

}

public function _up(){}

public function _down(){}

public function function1($data){}

public function function1_response($data){}

...........

}

/* End of file Skeleton.php */

/* Location: service/modules */

User Interface

Main Environment Service Environment

DataSource

FormSource

ModelInterface

GridModel Slots

Ext-Js Libraries Interface Controler(complex.php)

Grid Form Model SlotspatienList

Css environment

customTable

inpatienForm

patienRoom

roomList

Inpatien module

SO

AP

Pac

k

Main Page(index.php)

Js environtment

Image

Bus / folder

file Reff as JS Script

Desain Sistem

Metodologi Penelitian

• Analisa Kebutuhan• Rancang dan Bangun CASE Tool

– Komponen Diagram Use Case– Komponen Diagram Sequence– Komponen Diagram Class– Komponen Diagram PDM– Komponen Generate Code – Komponen CodeEditor– Komponen Deploy And Testing

• Testing

Kebutuhan CASE Tool

Hubungan Antara CASE Tool denganKerangka Kerja OHIS

Hubungan Antar Layanan

Desain CASE Tool

Basic GUI

GraphPanel ToolbarNode Node

Sequence pada penggunaankomponen diagram

Clone Method

Prototype DesignPattern

Desain untuk komponen diagram use case

Basic GUI

Actor Properties

Use Case Properties

Desain Komponen Diagram Sequence

Basic Gui

Desain Komponen Diagram Class

Basic GUI

Class Properties

Desain Komponen diagram PDM

Basic GUI

Table Properties

Table Properties

Pemetaan Class ke Tabel

Table Data Gateway DesignPattern

Entity Class => Implementasi Table Data Gateway Pattern

Unit Of Work DesignPattern

Unit Of Work : How to

Singleton DesignPattern

Desain Sistem untuk Generate Code

Desain Sistem untuk Generate Code

Basic GUI

Desain untuk Komponen Deploy

Uji Coba

• Tujuan dari pengujian kali ini adalah untukmelakukan simulasi pada pembuatan layananRekamMedis sehingga dapat memperlihatkanbagaimana CASE Tool ini dapat mempermudahhal – hal yang masih rumit jika membangunlayanan secara koding, terutama pada bagiandesain layanan, desain basis data pada layanan,desain query pada layanan, pemilihan modeltampilan user, penggunaan layanan lain, registrasilayanan beserta fungsi dan aktivitasnya, instalasidan testing dari layanan.

Data yang Diujikan• Layanan yang akan dibangun untuk keperluan ujicoba

adalah layanan rekam medis, dimana terdapat layananlain yang dengan asumsi telah terinstall sebelumnyaadalah layanan pasien. Spesifikasi fitur dan fungsi darilayanan rekam medik setelah diadaptasi dari dokumenSKPL adalah sebagai berikut :

• Fitur kondisi

– Fungsi lihat daftar riwayat kondisi

– Fungsi tambah kondisi

– Fungsi edit kondisi

*Nisafani A.S, Fithroni A (2009)Spesifikasi Kebutuhan Perangkat Lunak (SKPL) Sistem Informasi Rumah Sakit Terpadu (SIRST) Release 2, Final Project Report, Jurusan Sistem Informasi, ITS

Gambaran Umum Pengujian

UseCase RekamMedis

Sequence : lihat daftar kondisi

Sequence : lihat daftar kondisi

Skenario : Use Case Lihat DaftarRiwayat Kondisi

Id Skenario Nama Skenario Kombinasi Flow

DRK1 Skenario Normal Normal Flow

DRK2 Data Pasien TidakAda

Exception 1

DRK3 Data RiwayatKondisi Tidak Ada

Exception 2

TestCase : lihat daftar kondisi

Id Skenario Menekan Menu Lihat Daftar

Tindakan Medis

Data Pasien Data Tindakan Medis

Hasil yang Diharapkan

DRK1 Ditekan Ada Ada Muncul DaftarRiwayat Kondisipada Pasien

DRK2 Ditekan Tidak Ada - Muncul Pesan“Data PasienTidakDitemukan”

DRK3 Ditekan Ada Tidak Ada Muncul Pesan“Data RiwayatKondisi TidakDitemukan”

Sequence : tambah kondisi

Sequence : tambah kondisi

Skenario : Tambah Kondisi

Id Skenario Nama Skenario Kombinasi Flow

TK1 Skenario Normal Normal Flow

TK2 Data Pasien TidakAda

Exception 1

TestCase : Tambah Kondisi

Id Skenario Menekan Menu

Tambah Kondisi

Data Pasien Mengisi Field Kondisi

Menekan Tombol

Send

Hasil yang Diharapkan

TK1 Ditekan Ada Diisi Ditekan MunculHalamanDaftarRiwayatKondisi

TK2 Ditekan Tidak Ada - - MunculPesan “DataPasien TidakDitemukan”

Sequence : edit kondisi

Skenario : edit kondisi

Id Skenario Nama Skenario Kombinasi Flow

EK1 Skenario Normal Normal Flow

Test Case : edit kondisi

Id Skenario MenekanMenu Edit

Kondisi

Mengisi Field

Kondisi

Menekan Tombol

Send

Hasil yang Diharapkan

EK1 Ditekan Diisi Ditekan MunculHalamanDaftarRiwayatKondisi

Uji Validitas Penghasilan Kode Layanan

• Sebelum melakukan uji coba berdasarkan skenario pada kasus simulasipembangunan layanan RekamMedis, maka yang perlu dilakukan terlebih dahuluadalah melakukan uji validitas pada hasil kode layanan yang dapat dihasilkan olehCASE Tool. Ada beberapa bagian yang penting untuk dilakukan pengujian validitasantara lain,

• (1) uji use case dengan fungsi yang dihasilkan,• (2) uji use case dengan kebutuhan terhadap layanan lain,• (3) uji use case dengan pendaftaran nama fungsi,• (4) uji use case dengan registrasi fungsi ke aktivitas,• (5) uji use case dengan registrasi hak akses terhadap aktivitas. Selain dari use case,

harus dilihat pula diagram – diagram yang telah dihasilkan pada diagram sequencedan class, antara lain:

• (6) uji kesesuaian antara class yang didesain dan yang dihasilkan. Bagian terakhiradalah uji berdasarkan diagram PDM dalam hal pembuatan tabel pada basis data,yaitu :

• (7) uji kesesuaian antara pembuatan tabel dengan yang dihasilkan kode layanan.

Kesesuaian Use Case - Fungsi yang dihasilkan

Use Case Fungsi yang Harus ada

Hasil uji

Daftar Kondisi lihat_daftar_kondisi OK

Tambah Kondisi tambah_kondisi OK

Tambah Kondisi tambah_kondisi_response

OK

Edit Kondisi edit_kondisi OK

Edit Kondisi edit_kondisi_response

OK

Pasien - OK

Kesesuaian dengan kebutuhanterhadap layanan lain

Use Case Layanan Yang Dibutuhkan Hasil Uji

Pasien Pasien OK

Kesesuaian nama pengganti dari fungsi

Use Case Nama lain fungsi Hasil Uji

DaftarKondisi

lihat_daftar_kondisi => DaftarKondisi

OK

TambahKondisi

tambah_kondisi => TambahKondisi

OK

Edit Kondisi edit_kondisi => Edit Kondisi OK

Kesesuaian Registrasi Fungsi Ke dalamAktivitas

Use Case Fungsi => Aktivitas Hasil Uji

Daftar Kondisi lihat_daftar_kondisi =>Kondisi

OK

Tambah Kondisi tambah_kondisi =>Kondisi

OK

Edit Kondisi edit_kondisi => Kondisi OK

Kesesuaian Terhadap Hak Akses padaAktivitas

Aktor Use Case Aktivitas Hasil Uji

Dokter DaftarKondisi

Kondisi OK

Dokter TambahKondisi

Kondisi OK

Dokter EditKondisi

Kondisi OK

Kesesuaian Pada Class yang dihasilkan

Class Extend TestClass Hasil Uji

RekamMedis ModuleClass RekamMedisTestSuite

OK

RiwayatKondisi - RiwayatKondisiTestCase

OK

DaftarKondisi - DaftarKondisiTestCase

OK

DaftarPasien - DaftarPasienTestCase

OK

Kondisi Entity KondisiTestCase OK

Kesesuaian antara class dan tabel yang dibentuk

Class Extend TableCreation

Hasil Uji

Kondisi Entity Kondisi OK

Uji Skenario

• Pengujian berdasarkan test case yang telahdibuat sebelumnya

Hasil Uji Lihat Daftar Kondisi

Id Skenario

Hasil Yang Diharapkan Hasil Test status

DRK1 Muncul Daftar Riwayat Kondisipada Pasien

Muncul Daftar RiwayatKondisi pada Pasien

OK

DRK2 Muncul Pesan “Data PasienTidak Ditemukan”

Muncul Pesan “DataPasien TidakDitemukan”

OK

DRK3 Muncul Pesan “Data RiwayatKondisi Tidak Ditemukan”

Muncul Pesan “DataRiwayat Kondisi TidakDitemukan”

OK

Snapshot : pilihan data pasien

Snapshot : DRK1

Snapshot : DRK 2

Snapshot : DRK3

Hasil Uji Use Case Tambah Kondisi

Id Skenario

Hasil yang Diharapkan

Hasil Test Status

TK1 Muncul HalamanDaftar RiwayatKondisi

Muncul HalamanDaftar RiwayatKondisi

OK

TK2 Muncul Pesan“Data PasienTidakDitemukan”

Muncul Pesan “DataPasien TidakDitemukan”

OK

Snapshot : Tambah Kondisi

Snapshot : TK1

Snapshot : Tk2

Hasil Uji Use Case Edit Kondisi

Id Skenario Hasil yang Diharapkan

Hasil Test Status

EK1 MunculHalaman DaftarRiwayat Kondisi

MunculHalaman DaftarRiwayat Kondisi

OK

Snapshot : edit kondisi

Snapshot : EK1

Kesimpulan

• CASE Tool telah berhasil melakukan pembuatan layanan, dengankasus Rekam Medis sesuai yang telah dilakukan pada uji coba.

• CASE Tool dapat melakukan desain layanan pada kerangka kerjaOHIS, dengan menggunakan beberapa diagram, yaitu : diagram usecase, diagram sequence, diagram class dan diagram PDM, yangnantinya akan dihasilkan kode layanan berdasarkan desain daridiagram – diagram tersebut.

• CASE Tool dapat mempermudah desain tabel dengan melihatkondisi dari desain pada diagram class yang merupakan turunandari class Entity.

• CASE Tool dapat mendeteksi penggunaan layanan lain sebagaisumber data melalui diagram use case dan hasilnya akan dapatdilihat pada kode yang telah dihasilkan.

Kesimpulan

• CASE Tool dapat mempermudah pekerjaan yang bersifat melakukanpendaftaran, seperti pendaftaran nama fungsi, pendaftaran fungsike dalam aktivitas, dan pendaftaran hak akses pada aktivitas yangkesemuanya didapatkan dari diagram use case.

• CASE Tool ini dengan memanfaatkan penghasilan kode layanandapat menuntun pengembang layanan agar tetap sesuai dankonsisten dengan desain yang telah dibangun.

• CASE Tool ini masih bersifat satu arah, belum dapat melakukanproses backward engineering sehingga pada proses pengkodingankode layanan dimungkinkan kehilangan konsistensi dengan desain.Karena dimungkinkan bagi para pengembang untuk menambahkanfungsi yang mungkin tidak terpikirkan sebelumnya saat prosesdesain.

Terima Kasih

Q & A