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
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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)
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()){}
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”
• 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.