PEMBANGUNAN PURWARUPA COMPUTER AIDED SOFTWARE ENGINEERING TOOL UNTUK PEMBUATAN LAYANAN PADA KERANGKA KERJA BERBASIS SERVICE ORIENTED ARCHITECTURE : OHIS Radityo PW (5107201008) Thesis PROGRAM MAGISTER BIDANG KEAHLIAN TEKNIK INFORMATIKA JURUSAN TEKNIK INFORMATIKA FAKULTAS TEKNOLOGI INFORMASI INSTITUT TEKNOLOGI SEPULUH NOPEMBER
Latar Belakang 95% Rumah Sakit di Indonesia masih manual[2]
pembangunan infrastruktur teknologi informasi kebutuhan strategik[3]
Masalah pada Framework OHIS
Otomatisasi dengan Sistem Informasi Trend Layanan Kesehatan General ke Spesifik [1] 1. 2. 3.
Framework OHIS
Kesesuaian dengan Desain
Penulisan Aturan2 Desain Pada coding
CASE Tool
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 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). LeRouge, C., Mantzana, V. dan Wilson, E.V. (2007) Healthcare information Systems research, revelations and visions. European Journal of Information Systems 16: 669–671.
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 service dikarenakan 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 Service menggunakan 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 dan PDM untuk desain dan pembangunan service menggunakan pola yang digunakan framework OHIS – – – – – –
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 sebuah aplikasi : – 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 ArgoUML
Yang diinginkan (berbasis Framework OHIS)
RawatInap.php Dokter.php
Perawat.php
Melihat_ja dwal_dokte r.php
Fungsi melihat_jadwal_dokter($data) Fungsi tersebut boleh diakses oleh dokter dan perawat
Framework OHIS model dasar arsitektur OHIS dimana terdapat 2 bagian utama, yaitu bagian Main dan bagian services yang pada gambar di atas adalah pharmacy, 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 dan fungsi Tambah kondisi pasien, maka pada layanan (service) akan dibuat :
Class RekamMedis extends ModuleClass{ function _up(){} function _down(){} function tambah_kondisi_pasien($data = array()){} }
Arsitektur Framework OHIS Data
5 6 Services Loader
4
6
Services Requester
4 Service Location List
7
2 3
Data Main Area
Template Parser
9
Client
Using HTTPS
Services
8
1
Skeleton dari Service berbasis PHP
User Interface Main Environment
Service Environment Inpatien module
Css environment
file
Reff as JS Script
Interface Controler (complex.php)
Ext-Js Libraries
SOAP Pack
Image
Main Page (index.php)
Bus / folder
Js environtment
customTa ble
GridModel
inpatienF orm
FormSource
patienRo om roomList
patienList Grid
Form
Model
Slots
ModelInterface
DataSource
Slots
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 dengan Kerangka Kerja OHIS
Hubungan Antar Layanan
Desain CASE Tool
Basic GUI
GraphPanel
Node
Node
Toolbar
Sequence pada penggunaan komponen 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 untuk melakukan simulasi pada pembuatan layanan RekamMedis sehingga dapat memperlihatkan bagaimana CASE Tool ini dapat mempermudah hal – hal yang masih rumit jika membangun layanan secara koding, terutama pada bagian desain layanan, desain basis data pada layanan, desain query pada layanan, pemilihan model tampilan user, penggunaan layanan lain, registrasi layanan beserta fungsi dan aktivitasnya, instalasi dan testing dari layanan.
Data yang Diujikan • Layanan yang akan dibangun untuk keperluan ujicoba adalah layanan rekam medis, dimana terdapat layanan lain yang dengan asumsi telah terinstall sebelumnya adalah layanan pasien. Spesifikasi fitur dan fungsi dari layanan rekam medik setelah diadaptasi dari dokumen SKPL 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 Daftar Riwayat Kondisi Id Skenario DRK1 DRK2 DRK3
Nama Skenario Kombinasi Flow Skenario Normal Normal Flow Data Pasien Tidak Exception 1 Ada Data Riwayat Exception 2 Kondisi Tidak Ada
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 Daftar Riwayat Kondisi pada Pasien
DRK2
Ditekan
Tidak Ada
-
DRK3
Ditekan
Ada
Tidak Ada
Muncul Pesan “Data Pasien Tidak Ditemukan” Muncul Pesan “Data Riwayat Kondisi Tidak Ditemukan”
Sequence : tambah kondisi
Sequence : tambah kondisi
Skenario : Tambah Kondisi Id Skenario TK1 TK2
Nama Skenario Kombinasi Flow Skenario Normal Normal Flow Data Pasien Tidak Exception 1 Ada
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
Muncul Halaman Daftar Riwayat Kondisi
TK2
Ditekan
Tidak Ada
-
-
Muncul Pesan “Data Pasien Tidak Ditemukan”
Sequence : edit kondisi
Skenario : edit kondisi
Id Skenario EK1
Nama Skenario Kombinasi Flow Skenario Normal Normal Flow
Test Case : edit kondisi Id Skenario
EK1
Menekan Mengisi Menu Edit Field Kondisi Kondisi Ditekan Diisi
Menekan Hasil yang Tombol Diharapkan Send Ditekan Muncul Halaman Daftar Riwayat Kondisi
Uji Validitas Penghasilan Kode Layanan •
• • • • •
• •
Sebelum melakukan uji coba berdasarkan skenario pada kasus simulasi pembangunan layanan RekamMedis, maka yang perlu dilakukan terlebih dahulu adalah melakukan uji validitas pada hasil kode layanan yang dapat dihasilkan oleh CASE Tool. Ada beberapa bagian yang penting untuk dilakukan pengujian validitas antara 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 sequence dan class, antara lain: (6) uji kesesuaian antara class yang didesain dan yang dihasilkan. Bagian terakhir adalah 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 Daftar Kondisi Tambah Kondisi Tambah Kondisi Edit Kondisi Edit Kondisi Pasien
Fungsi yang Harus ada lihat_daftar_kondisi tambah_kondisi tambah_kondisi_resp onse edit_kondisi edit_kondisi_respons e -
Hasil uji OK OK OK OK OK OK
Kesesuaian dengan kebutuhan terhadap layanan lain
Use Case Layanan Yang Dibutuhkan Pasien Pasien
Hasil Uji OK
Kesesuaian nama pengganti dari fungsi
Use Case Daftar Kondisi Tambah Kondisi Edit Kondisi
Nama lain fungsi Hasil Uji lihat_daftar_kondisi => Daftar OK Kondisi tambah_kondisi => Tambah OK Kondisi edit_kondisi => Edit Kondisi OK
Kesesuaian Registrasi Fungsi Ke dalam Aktivitas Use Case Daftar Kondisi
Fungsi => Aktivitas
Hasil Uji
lihat_daftar_kondisi => OK Kondisi Tambah Kondisi tambah_kondisi => OK Kondisi Edit Kondisi edit_kondisi => Kondisi OK
Kesesuaian Terhadap Hak Akses pada Aktivitas Aktor Dokter
Dokter Dokter
Use Case Daftar Kondisi Tambah Kondisi Edit Kondisi
Aktivitas Hasil Uji Kondisi OK
Kondisi
OK
Kondisi
OK
Kesesuaian Pada Class yang dihasilkan Class RekamMedis
Extend TestClass ModuleClass RekamMedisTes tSuite RiwayatKondisi RiwayatKondisiT estCase DaftarKondisi DaftarKondisiTe stCase DaftarPasien DaftarPasienTes tCase Kondisi Entity KondisiTestCase
Hasil Uji OK OK OK OK OK
Kesesuaian antara class dan tabel yang dibentuk
Class
Extend
Kondisi
Entity
TableCreati Hasil Uji on Kondisi OK
Uji Skenario • Pengujian berdasarkan test case yang telah dibuat sebelumnya
Hasil Uji Lihat Daftar Kondisi Id Skenario
Hasil Yang Diharapkan
Hasil Test
status
DRK1
Muncul Daftar Riwayat Kondisi Muncul Daftar Riwayat OK pada Pasien Kondisi pada Pasien
DRK2
Muncul Pesan “Data Pasien Muncul Pesan “Data OK Tidak Ditemukan” Pasien Tidak Ditemukan”
DRK3
Muncul Pesan “Data Riwayat Muncul Pesan “Data OK Kondisi Tidak Ditemukan” Riwayat Kondisi Tidak Ditemukan”
Snapshot : pilihan data pasien
Snapshot : DRK1
Snapshot : DRK 2
Snapshot : DRK3
Hasil Uji Use Case Tambah Kondisi Id Hasil yang Hasil Test Status Skenario Diharapkan TK1 Muncul Halaman Muncul Halaman OK Daftar Riwayat Daftar Riwayat Kondisi Kondisi TK2 Muncul Pesan Muncul Pesan “Data OK “Data Pasien Pasien Tidak Tidak Ditemukan” Ditemukan”
Snapshot : Tambah Kondisi
Snapshot : TK1
Snapshot : Tk2
Hasil Uji Use Case Edit Kondisi
Id Skenario EK1
Hasil yang Hasil Test Status Diharapkan Muncul Muncul OK Halaman Daftar Halaman Daftar Riwayat Kondisi Riwayat Kondisi
Snapshot : edit kondisi
Snapshot : EK1
Kesimpulan • CASE Tool telah berhasil melakukan pembuatan layanan, dengan kasus Rekam Medis sesuai yang telah dilakukan pada uji coba. • CASE Tool dapat melakukan desain layanan pada kerangka kerja OHIS, dengan menggunakan beberapa diagram, yaitu : diagram use case, diagram sequence, diagram class dan diagram PDM, yang nantinya akan dihasilkan kode layanan berdasarkan desain dari diagram – diagram tersebut. • CASE Tool dapat mempermudah desain tabel dengan melihat kondisi dari desain pada diagram class yang merupakan turunan dari class Entity. • CASE Tool dapat mendeteksi penggunaan layanan lain sebagai sumber data melalui diagram use case dan hasilnya akan dapat dilihat pada kode yang telah dihasilkan.
Kesimpulan • CASE Tool dapat mempermudah pekerjaan yang bersifat melakukan pendaftaran, seperti pendaftaran nama fungsi, pendaftaran fungsi ke dalam aktivitas, dan pendaftaran hak akses pada aktivitas yang kesemuanya didapatkan dari diagram use case. • CASE Tool ini dengan memanfaatkan penghasilan kode layanan dapat menuntun pengembang layanan agar tetap sesuai dan konsisten dengan desain yang telah dibangun. • CASE Tool ini masih bersifat satu arah, belum dapat melakukan proses backward engineering sehingga pada proses pengkodingan kode layanan dimungkinkan kehilangan konsistensi dengan desain. Karena dimungkinkan bagi para pengembang untuk menambahkan fungsi yang mungkin tidak terpikirkan sebelumnya saat proses desain.
Terima Kasih Q&A
