Penerapan Service Oriented Architecture
advertisement
4 Tahap Pengujian Pengujian Hasil implementasi kemudian diuji dan dievaluasi, selanjutnya pengujian dibandingkan dengan hasil uji yang diharapkan. Apabila tidak sesuai dengan yang diharapkan akan dilakukan perbaikan kemudian diuji kembali, sampai memenuhi hasil yang diharapkan. Tahap ini dilakukan dengan memeriksa apakah semua service telah memenuhi spesifikasi kebutuhan yang telah ditentukan melalui antarmuka yang telah dibuat. Jika sudah tidak ditemukan kesalahan pada seluruh service, suatu perangkat lunak akan dibuat untuk uji interoperability. Perangkat lunak ini dibuat dengan lingkungan pengembangan yang berbeda dan mampu mengonsumsi service yang telah dibuat. METODE PENELITIAN Pengembangan sistem informasi akademik akan menerapkan SOA dengan metode pengembangan linear sequential model. Analisis Kebutuhan Tahap ini dilakukan untuk mengidentifikasi kebutuhan sistem yang akan dikembangkan dan tipe pengguna sistem. Kebutuhan meliputi kebutuhan fungsional dan kebutuhan non fungsional. Kebutuhan fungsional dimodelkan dengan pembuatan diagram use case dan instrumen lain untuk memudahkan pemahaman dalam tahap selanjutnya. Kebutuhan sistem dipengaruhi oleh tipe pengguna sistem. Perancangan Aktivitas dalam tahap perancangan meliputi perancangan basis data yang diwujudkan dengan pembuatan Entity Relationship Diagram (ERD). Pembuatan diagram Unified Modelling Language (UML) untuk pemodelan objek dalam sistem baik objek yang berfungsi sebagai penyedia service maupun eksekutor proses bisnis, serta pemodelan arsitektur sistem. Implementasi Tahap ini dilakukan untuk menransformasi model pada tahap perancangan menjadi kodekode yang bisa dieksekusi komputer untuk setiap tier sistem. Untuk data provider, wujud implementasinya adalah kueri berbasis pemrograman yang dapat dieksekusi oleh DBMS. Untuk Business service, wujud implementasinya adalah kumpulan kelas yang saling bekerjasama untuk mencapai tujuan tertentu. Kumpulan kelas tersebut digunakan untuk pembuatan service. Untuk user interface wujud implementasinya adalah antarmuka yang berinteraksi langsung dengan pengguna serta meminta service. Berbagai service yang dihasilkan dipublikasikan ke server UDDI. Lingkungan Implementasi Lingkungan implementasi yang digunakan adalah sebagai berikut: Perangkat lunak: Microsoft Windows Server 2003 SP 2, IIS Versi 6, Microsoft SQL Server 2005, Microsoft Visual Studio 2005, Microsoft Office Visio 2003, Crystal report 11, VMWare Workstation 4.5.2, Microsoft Windows XP SP2, WOS Portable 2 (PHP 5.1.6, Apache 2, Mysql 5), Zend Studio 5, Mozilla Firefox 2. Perangkat keras: Prosesor Intel Pentium IV 2.8 GHz, RAM 1430 MB, harddisk 80 GB, keyboard, mouse, dan monitor. HASIL DAN PEMBAHASAN Analisis kebutuhan Tahap analisis kebutuhan meliputi identifikasi pengguna, membuat daftar kebutuhan fungsional serta pemodelannya, dan mengidentifikasi kebutuhan non fungsional. Identifikasi Pengguna Sistem Pengguna sistem dikategorikan menjadi tiga, yaitu mahasiswa, pegawai staf akademik departemen, dan staf kantor Administrasi dan Jaminan Mutu Pendidikan (AJMP). Setiap kategori pengguna memiliki hak akses yang berbeda terhadap fitur sistem. Setiap pengguna sistem memiliki identitas pengenal dan password yang unik dan disimpan dalam basis data. Identitas pengenal dan password digunakan tatkala akan memasuki sistem. Kebutuhan Fungsional Sistem yang dikembangkan harus mampu melakukan operasi terhadap data dalam basis data. Operasi meliputi penambahan, penghapusan, pengubahan dan pencarian yang biasa disingkat CRUD (Create, Read, Update, Delete). Data yang dikelola meliputi data 5 model kurikulum mayor-minor dan passing out. 20 21 Untuk memudahkan proses administrasi, sistem harus mampu membangkitkan dokumen yang siap dicetak. Dokumen memiliki format tetap namun isinya berbeda sesuai parameter masukan dalam operasi serta data yang dilibatkan. Pemodelan Kebutuhan Fungsional Pemodelan dilakukan untuk memudahkan pemahaman dan mengomunikasikan tujuan suatu kebutuhan serta pihak-pihak yang terlibat. Pemodelan dilakukan dengan pembuatan diagram use case yang menggambarkan aktor beserta use case dalam sistem. Aktor ialah segala sesuatu yang berinteraksi secara langsung dengan sistem, baik manusia maupun non manusia. Dalam penelitian ini, aktor meliputi mahasiswa, staf administrasi akademik departemen, staf kantor AJMP, sistem pengelolaan pembayaran SPP di bank, dan sistem pencatatan peminjaman dan pengembalian buku di perpustakaan. Aktor manusia digambarkan sebagai garisgaris dan lingkaran sedangkan aktor non manusia digambarkan dengan kotak dengan stereotype aktor. Pemodelan sistem dibagi menjadi empat subsistem berdasarkan data yang dikelola. Keempat subsistem tersebut adalah subsistem manajemen data akademik, subsistem manajemen data mahasiswa, subsistem manajemen data wisuda, dan subsistem manajemen data SPP. Pembagian sistem ke dalam empat subsistem juga dapat mempermudah pembacaan diagram use case. Diagram Use case disajikan pada Gambar 5 hingga Gambar 8. Jika terdapat operasi yang menyebabkan perubahan data dalam basis data, sistem harus mencatat informasi yang bersangkutan dengan operasi tersebut dalam sebuah log file. Kebutuhan fungsional selengkapnya adalah: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Memeriksa validitas operator Memeriksa validitas mahasiswa sistem Menyimpan data KRS Mengubah data KRS Mencari data KRS Menyimpan data mata kuliah Mengubah data mata kuliah Menghapus data mata kuliah Mencari data mata kuliah Mengelola data tugas akhir Mencetak transkrip Mencetak daftar kuliah Mencetak KRS Menyimpan data mahasiswa Mengubah data mahasiswa Menghapus data mahasiswa Mencari data mahasiswa Memeriksa kelengkapan syarat wisuda Mengelola data SPP Membaca data pembayaran SPP Mencatat history/log sistem <<system>> Sistem Informasi Kemahasiswaan <<SubSystem>> Manajemen Data Mahasiswa Operator pegawai AJMP menyimpan data << mahasiswa in <<inc cl u lude> > de >> mengubah data <<i n cl mahasiswa u Staff administrasi akademik departemen clu <<in cl u inc << >> memeriksa validitas operator de> > de >> menghapus data <<in mahasiswa <<In e lud de>> clud de>> <<inclu e>> mencatat history/log sistem mencari data mahasiswa Gambar 5 Diagram use case subsistem manajemen data mahasiswa. 6 <<system>> Sistem Informasi Kemahasiswaan <<SubSystem>> Manajemen Data Akademik mencetak transkrip nilai mahasiswa mencetak daftar kuliah mencetak KRS menyimpan data KRS mencatat history/log sistem mengubah data KRS Operator pegawai AJMP mencari data KRS menyimpan data mata kuliah Staff administrasi akademik departemen memeriksa validitas operator mengubah data mata kuliah menghapus data mata kuliah mencari data mata kuliah mahasiswa memeriksa validitas mahasiswa Mengelola data tugas akhir Gambar 6 Diagram use case subsistem manajemen data akademik. <<system>> Sistem Informasi Kemahasiswaan <<SubSystem>> Manajemen Data Wisuda <<include>> memeriksa kelengkapan syarat wisuda memeriksa validitas operator <<aktor>> Sistem manajemen Transaksi keuangan bank Operator pegawai AJMP <<aktor>> Sistem pencatatan peminjaman/ pengembalian buku perpustakaan Gambar 7 Diagram use case subsistem manajemen data wisuda. 7 <<system>> Sistem Informasi Kemahasiswaan <<SubSystem>> Pembayaran SPP > lude> Mengelola data SPP <<<<inincc lud memeriksa validitas operator e>> mencatat history/log sistem Operator pegawai AJMP membaca data pembayaran SPP <<aktor>> Sistem manajemen Transaksi keuangan bank Gambar 8 Diagram use case subsistem pembayaran SPP. Setiap Use case memiliki skenario utama dan beberapa skenario alternatif. Diagram Use case tidak mendeskripsikan secara jelas jalur skenario, jadi diperlukan instrumen tersendiri untuk menjelaskannya. Untuk mendeskripsikan jalur skenario setiap Use case digunakan table-oriented steps yang terdapat pada Lampiran 1. Kebutuhan Antarmuka dan Komunikasi Sistem memerlukan antamuka berbasis web yang bisa diakses melalui web browser dan antarmuka operator client yang diakses melalui komputer khususnya yang terhubung dalam intranet. Sistem melibatkan lebih dari satu komputer yang saling terhubung melalui jaringan baik intranet maupun internet. Komunikasi antarkomputer dilakukan dengan protokol TCP/IP yang mampu melewatkan data berbasis teks. Perancangan Penerapan SOA pada sistem memungkinkan sistem menyediakan fungsi yang dapat dipakai oleh sistem lain. Fungsi sistem harus mengakses basis data dan mengakomodasi proses bisnis tertentu. Dengan demikian sistem melibatkan banyak pengguna dan melibatkan jaringan komputer. Antarmuka sistem melibatkan antarmuka berbasis web untuk diakses melalui internet dan operator client untuk lingkungan intranet. Arsitektur Model Aplikasi Sistem dibagi menjadi tiga lapisan, yaitu user interface, business service dan data provider. Lapisan User interface berinteraksi langsung dengan pengguna yaitu mahasiswa, staf administrasi akademik departemen, dan staf kantor AJMP. Pengguna memberikan masukan, menerima data dan memodifikasinya melalui lapisan ini. Wujud nyata lapisan user interface adalah halaman web dan antarmuka operator client. Lapisan business service menyediakan service bagi lapisan user interface dan mengolah data yang diambil dari lapisan data provider. Lapisan business service terdiri atas kumpulan komponen yang mengeksekusi fungsi tertentu dan menghasilkan dokumen WSDL yang mendeskripsikan service. Lapisan data provider melibatkan DBMS untuk memanipulasi, menyimpan, dan menyediakan data. Ketiga proses tersebut menggunakan Stored procedure dan berbagai kelas. Perancangan Basis Data Entitas yang diperlukan adalah pengguna sistem, pegawai, fakultas, departemen, mahasiswa, mata kuliah, KRS, SPP, dosen, tugas akhir. Entitas Mahasiswa memiliki atribut agama dan jalur masuk yang nilainya spesifik. Karena agama dan jalur masuk hanya memiliki beberapa kemungkinan dan masingmasing kemungkinan dapat memiliki atribut tambahan yang spesifik, maka agama dan jalur masuk dijadikan entitas. Data mata kuliah yang terlibat dalam sistem meliputi mata kuliah mayor-minor dan passing out. Mata kuliah mayor-minor memiliki atribut yang berbeda dengan mata kuliah passing out, sehingga muncul entitas mata kuliah mayorminor dan mata kuliah passing out. SPP yang dikelola juga memilki tipe mayor-minor dan passing out. Atribut SPP mayor-minor lebih banyak daripada SPP passing out sehingga muncul entitas SPP mayor-minor. Seorang mahasiswa dapat mengambil banyak mata kuliah dan satu mata kuliah 8 dapat diambil banyak mahasiswa, sehingga keterhubungan “mengambil” antar mahasiswa dan mata kuliah adalah N:N. Keterhubungan antara mahasiswa dan mata kuliah merupakan konsekuensi dari keterhubungan menentukan antara mahasiswa dan KRS, sehingga keterhubungan antara mahasiswa dan mata kuliah merupakan realisasi penentuan KRS dengan bentuk nyata adalah kuliah. Dengan demikian keterhubungan antara mahasiswa dan mata kuliah lebih tepat memiliki nama “kuliah”. Entitas tugas akhir dan dosen juga memiliki keterhubungan N:N. Seorang dosen dapat membimbing banyak tugas akhir dan satu tugas akhir dapat dibimbing oleh dua atau lebih dosen. Nama keterhubungan adalah “bimbingan tugas akhir”. Mahasiswa dan pegawai bisa menjadi pengguna sistem. Setiap mahasiswa dan pegawai memiliki identitas yang unik sehingga entitas mahasiswa dan pegawai memiliki keterhubungan 1:1 dengan entitas pengguna sistem dengan nama keterhubungan “menjadi”. Mahasiswa memiliki 1 agama dan diterima di universitas melalui satu jalur penerimaan, sehingga entitas mahasiswa memiliki keterhubungan 1:1 dengan entitas agama dengan nama keterhubungan “menganut” dan memiliki keterhubungan 1:1 dengan entitas jalur masuk dengan nama keterhubungan “melalui”. Satu mahasiswa diwajibkan menyelesaikan satu tugas akhir, sehingga entitas mahasiswa memiliki keterhubungan 1:1 dengan entitas tugas akhir dengan nama keterhubungan “menyelesaikan”. Setiap KRS dapat disahkan jika SPP telah dibayar, sehingga entitas KRS memiliki keterhubungan 1:1 dengan entitas SPP dengan nama keterhubungan “membiayai”. Satu mata kuliah mata passing out bisa menjadi syarat bagi mata kuliah passing out lainnya, dengan demikian entitas mata kuliah memiliki keterhubungan 1:N dengan dirinya sendiri dengn nama keterhubungan “mensyaratkan”. Hal ini terjadi juga pada entitas mata kuliah mayor minor. Satu fakultas terdiri atas beberapa departemen dan satu departemen hanya terdapat pada satu fakultas, sehingga entitas fakultas memiliki keterhubungan 1:N dengan entitas departemen dengan nama keterhubungan “membawahi”. Seorang mahasiswa hanya dapat memilih satu departemen dan satu departemen memiliki banyak mahasiswa, sehingga entitas mahasiswa memiliki keterhubungan 1:N dengan entitas departemen dengan nama keterhubungan “memilih”. Seorang mahasiswa wajib membayar SPP setiap semester dan satu SPP dibayar atas nama hanya satu mahasiswa, dengan demikian entitas mahasiswa memiliki keterhubungan 1:N dengan entitas SPP dengan nama keterhubungan “membayar”. Seorang mahasiswa wajib menentukan KRS pada setiap semester dan satu KRS hanya berlaku untuk satu mahasiswa, sehingga entitas mahasiswa memiliki keterhubungan 1:N dengan KRS dengan nama keterhubungan “menentukan”. Seorang dosen dapat mengesahkan banyak KRS pada setiap semester dan satu KRS hanya dapat disahkan oleh satu dosen, sehingga entitas dosen memiliki keterhubungan 1:N dengan KRS dengan nama keterhubungan “menandatangani”. Entitas memiliki lebih dari satu atribut. Satu atau lebih atribut pada setiap entitas menjadi primary key. Entitas dan primaty key dimodelkan dengan ERD pada Gambar 9 sedangkan atribut entitas secara lengkap terdapat Lampiran 2. 9 Departemen KodePeg PenggunaSistem Pegawai 1 1 N KodeMK JalurMasukIPB MataKuliahMami 1 Menjadi 1 1 Membawahi KodeJalurMasuk N Fakultas ID 1 KodeDept 1 KodeFak Mensyaratkan 1 Menjadi Melalui Memilih KodeMK Bertipe N 1 Nim KodeMK N KodeKRS Nim Mahasiswa N 1 MataKuliah N Mengikuti 1 1 1 MataKuliahPO 1 Bertipe Mengikuti 1 N 1 N 1 KodeSKL Membayar Mensyaratkan N 1 Wisuda Nim N Nim KodeKRS Menentukan KodeAgama Menganut Membiayai 1 SPP 1 1 Agama Bertipe Merealisasikan 1 1 KodeTA N Menyelesaikan SPPMayorMinor 1 N TugasAkhir KodeTA Membimbing KRS Nip N Nip Nim KodeKRS N Dosen 1 1 Menandatangani NamaDosen KodeKRS Gambar 9 Entity relationship diagram. Identifikasi Kelas Domain Kelas domain merupakan kelas stabil yang dapat digunakan kembali berdasarkan dunia nyata dan merepresentasikan domain bisnis tertentu. Kelas domain pada sistem informasi akademik yaitu mata kuliah, SPP, mahasiswa, dokumen cetak, tugas akhir, KRS, dan syarat wisuda. Kelas domain digunakan pada lapisan business service untuk melakukan fungsi tertentu. Selain kelas domain tersebut, diperlukan kelas pendukung yang mendukung terpenuhinya kebutuhan fungsional. Adanya kebutuhan fungsional mencatat log operasi yang mengubah data menyebabkan perlunya kelas pengguna, log dan penulis log. Sistem harus mampu melakukan operasi pencarian data yang setiap hasil yang ditemukan diwujudkan dalam kelas domain. Operasi tersebut dilakukan oleh kelas pencari. Setiap kelas domain hasil pencarian dikumpulkan pada suatu kelas tertentu. Kelas yang menampung kelas domain ialah kelas daftar yang merupakan kelas abstrak turunan kelas CollectionBase dalam .Net Framework. Seluruh kelas domain dimodelkan dalam kelas diagram pada Gambar 10. 10 Pencari Daftar +ParameterPencarian[1] : String +KriteriaPencarian[1] : String +New() +CariBerdasarkan(in KriteriaPencarian : String, in YangDicari : String) : DaftarHasilPencarian memeriksa 1 1 memakai 1 memohon4 1 melunasi 1 DokCetak 1 1 1 1 mengelola mengambil 1 mengelola 1 mengelola 1 1 1 Pengguna -Username[1] : String -Level[1] : LevelPengguna -Bagian[1] : String -AlamatIP[1] : String -Antarmuka[1] : JenisAntarmuka -WaktuLogin[1] : Date +New() 1 1 +Pemohon[1] : Mahasiswa +Pencetak[1] : Pengguna +TanggalCetak[1] : Date +WaktuCetak[1] : Date +TahunAkademik[1] : String = 1000/1001 +Semester[1] : JenisSemester = ganjil +TingkatStudi[1] : JenisTingkatStudi = TPB +KodeTempatStudi[1] : String +SudahTercetak[1] : Boolean +New() +Mencetak() 1 1 SPP memeriksa 1 1 +Pembayar[1] : Mahasiswa +UntukPembayaran[1] : KRS +BatasWaktuPembayaran[1] : Date +TanggalPembayaran[1] : Date +NilaiPembayaran[1] : Integer +SudahLunas[1] : Boolean +TotalBiayaSPP[1] : Integer +Keterangan[1] : String +BPMK[1] : Integer +BPMP[1] : Integer +BPIF[1] : Integer +Status[1] : StatusSPP +New() +HitungTotalBiayaSPP() : Integer +UbahDataSPP() +SimpanDataSPP() +HapusDataSPP() TugasAkhir +Kode[1] : String +Judul[1] : String +Peneliti[1] : Mahasiswa +NamaPembimbing[1..*] : String +NrpPembimbing[1..*] : String +New() +SimpanTugasAkhir() +UbahTugasAkhir() +HapusTugasAkhir() KRS +KodeKRS[1] : String +TahunAkademik[1] : String = 1000/1001 -SemesterKe[1] : JenisSemester +JumlahSKS[1] : Byte +JumlahSKSKumulatif[1] : Byte +NIPDosen[1] : String +NamaDosen[1] : String +Pengambil[1] : Mahasiswa +MataKuliahYangDiambil[1] : DaftarPilihanMataKuliah +New() +DapatkanDaftarPilihanMataKuliah(in KodeKRS : String) : DaftarPilihanMataKuliah +HitungJumlahSKS(in MataKuliahYangDiambil : DaftarPilihanMataKuliah) : Byte +SimpanKRS() +UbahKRS() +HapusKRS() 1 1 mencari info mencatat 1 memenuhi mengelola 1 mencatat MataKuliah +Kode[1] : String +Nama[1] : String +JumlahSKS[1] : Byte +SKSKuliah[1] : Byte +SKSPraktikum[1] : Byte +KodeMataKuliahSyarat[1] : String +Deskripsi[1] : String +New() +KapanDiselenggarakan() : String +IdentifikasiDepartemen() : String +SimpanMataKuliah() +UbahMataKuliah() +HapusMataKuliah() +New() +TambahItem() +ItemSelanjutnya() +ItemSebelumnya() +HapusItem() +HitungJumlahItem() : Integer 1 menyelesaikan 1 +Nim[1] : String +Nama[1] : String +TanggalLahir[1] : Date +AsalSMU[1] : String +Kelamin[1] : JenisKelamin +Agama[1] : Agama +AlamatAsal[1] : String +AlamatLokal[1] : String +TahunMasuk[1] : Integer +StatusStudi[1] : StatusStudi +StatusPernikahan[1] : StatusPernikahan +JalurMasukIPB[1] : JalusMasukIPB +KotaAsal[1] : String +KodeDepartemen[1] : String +New() +SimpanMahasiswa() +UbahMahasiswa() +HapusMahasiswa() +DapatkanNamaDepartemen() : String +DapatkanKodeFakultas() : String +DapatkanNamaFakultas() : String 1 1 1 Mahasiswa 1 +Item[1] : String 1 SyaratWisuda 1 +YangHarusMemenuhi[1] : Mahasiswa +SyaratBebanStudiTerpenuhi[1] : Boolean +SyaratSemuaSudahLunas[1] : Boolean +SyaratSudahBebasPustaka[1] : Boolean +New() +MemeriksaSyaratBebabStudiTerpenuhi(in CalonWisudawan : Mahasiswa) : Boolean 1 1 1 menulis 1 Log -Operasi[1] : JenisOperasi -TargetOperasi[1] : String -WaktuOperasi[1] : Date -PemakaiSistem[1] : Pengguna +New() PenulisLog +Posisi[1] : String +Tulis(in Log : Log) +TentukanPosisiFile(in Posisi : String) Gambar 10 Diagram kelas domain. Kelas domain mata kuliah memiliki dua turun yaitu kelas mata kuliah passing out dan mata kuliah mayor-minor. Hal ini karena sistem melibatkan data mata kuliah passing out dan mata kuliah mayor minor yang memiliki atribut dan fungsi yang berbeda. Dengan alasan yang sama, kelas domain SPP juga memiliki dua turunan yaitu kelas SPP passing out dan kelas SPP mayor minor. Pemodelan kelas domain mata kuliah pada Lampiran 3 sedangkan kelas domain SPP pada Lampiran 4. Kelas domain dokumen cetak merupakan kelas abstrak. Kelas ini memiliki turunan yang menyediakan informasi yang akan dicetak. Kebutuhan fungsional sistem di antaranya ialah mencetak KRS, daftar kuliah, dan transkrip nilai. Berbagai kelas yang digunakan untuk memenuhi kebutuhan fungsional tersebut adalah kelas turunan kelas domain dokumen cetak yang dimodelkan dengan diagram pada Lampiran 5. Kelas daftar memiliki dua turunan. Pertama ialah kelas daftar domain yang 11 berfungsi untuk mengumpulkan kelas domain dan kedua ialah kelas daftar hasil pencarian yang berfungsi mengumpulkan berbagai kelas yang terbentuk dari hasil pencarian. Kelas daftar beserta kedua turunannya dimodelkan pada Lampiran 6. Kelas daftar domain dan kelas daftar hasil pencarian diturunkan lagi sesuai untuk memenuhi kebutuhan fungsional. Sebagai contoh, kebutuhan fungsional mencetak transkrip nilai memerlukan kelas yang memiliki properti yang bertipe nilai mahasiswa. Kelas ini adalah kelas daftar nilai yang merupakan turunan dari kelas daftar domain. Kelas daftar domain beserta turunannya dimodelkan dalam Lampiran 7. Contoh lainnya, kebutuhan fungsional mencari data mahasiswa memerlukan kelas yang menampung kelas mahasiswa yang terbentuk dari hasil pencarian data, kelas ini adalah kelas daftar hasil pencarian mahasiswa dan merupakan turunan kelas daftar hasil pencarian. Kelas daftar hasil pencarian beserta turunannya domodelkan pada Lampiran 8. Kelas pencari berfungsi memenuhi kebutuhan fungsional pencarian data, sehingga kelas pencari diturunkan sesuai dengan data yang dicari. Sebagai contoh, kebutuhan fungsional mencari mata kuliah melibatkan kelas pencari mata kuliah yang merupakan turunan kelas pencari. Kelas pencari beserta turunannya dimodelkan pada Lampiran 9. Identifikasi Interaksinya Kelas Aplikasi dan Kelas aplikasi merupakan semua kelas terdapat pada sistem baik pada lapisan user interface, business service, maupun data provider. Kelas aplikasi dari ketiga lapiasan saling berinteraksi untuk menyelesaikan satu use case tertentu. Sebagai contoh pada use case mencari data mahasiswa. Kelas aplikasi pada lapisan data provider berfungsi memanggil stored procedure dan menampung hasil eksekusinya. Kelas aplikasi ini kemudian memberikan datanya kepada kelas aplikasi pada lapisan business service untuk menginisiasi kelas domain yang sesuai. Ketika pemrosesan data telah terpenuhi pada lapisan business service, langkah selanjutnya adalah menampilkan hasil melalui kelas pada lapisan user interface. Kelas aplikasi dibagi menjadi tiga golongan, yaitu kelas controller, kelas view, dan kelas boundary. Kelas controller adalah kelas yang mengelola interaksi antara pengguna dan kelas domain dalam aplikasi atau sistem. Controller mengetahui kapan meminta domain kelas menjalankan aplikasi. Controller kelas biasanya ditambahkan untuk setiap use case. Fungsi utama controller adalah meyakinkan pengguna berinteraksi dengan sistem sesuai definisi pada use case. Kelas view memiliki fungsi utama mengelola antamuka pengguna yang membatasi pengguna dengan sistem. Setiap kelas view mengetahui bagaimana menampilkan kelas domain dengan tampilan yang spesifik. Kelas boundary berinteraksi dengan sistem lain, basis data, dan piranti eksternal dengan sistem yang dibuat, sebagai contoh, sebuah kelas boundary digunakan untuk memisahkan sistem yang dibuat dari basis data. Jika objek apapun dalam aplikasi memerlukan data dari basis data, objek ini meminta kelas boundary untuk mengambil data dari basis data. Dengan demikian jika basis data berubah, hanya kerja internal dalam kelas boundary yang harus disesuaikan. Ketiga golongan kelas aplikasi memiliki ciri khusus pada namanya. Kelas controller memiliki nama dengan akhiran manager, sebagai contoh KRSManager dan MahasiswaManager. Kelas view memiliki nama dengan awalan UI, sebagai contoh UISPPPO dan UIMahasiswa. Kelas boundary yang memiliki nama dengan awalan DBAccessor, sebagai contoh DBAccessorUntukMataKuliah. Interaksi kelas aplikasi pada untuk use case melibatkan kelas service yang merupakan turunan dari kelas dalam .Net framework yaitu kelas WebService dalam namespace System.Web.Services. Kelas service mampu menggunakan secara langsung objek-objek dalam .Net Framework untuk mengekspos XML Web Service. Interaksi kelas aplikasi dimodelkan dengan sequence diagram pada Lampiran 10. Perancangan Arsitektur Fisik Antarmuka sistem meliputi antamuka berbasis web dan operator client. Antarmuka berbasis web diperuntukkan bagi pengguna mahasiswa sedangkan operator client diperuntukkan bagi pengguna staf administrasi departemen dan staf kantor AJMP. Halaman web sistem dapat diakses melalui komputer yang terhubung dengan internet, sedangkan antarmuka operator client hanya dapat berfungsi pada komputer dalam intranet. 12 mengeksekusi proses bisnis dan mempublikasikan service terdapat dalam application server. Dengan demikian application server merupakan target operasi publish, find dan bind terhadap service. Application server dapat mengambil data pada database server. Tempat penyimpanan semua data adalah database server. Pemisahan server menjadi tiga agar beban sistem tidak tertumpu pada satu sumber daya dan memudahkan pemeliharaan seperti pada Gambar 11. Terdapat tiga server yang digunakan dalam sistem ,yaitu web server, application server, dan database server. Web server berfungsi menyediakan layanan antarmuka kepada pengguna yang mengakses melalui internet. Halaman-halaman web yang merupakan lapisan user interface disimpan pada directory dalam web server. Applicaton server berfungsi menyediakan service yang dapat dikonsumsi oleh halaman web pada web server maupun antarmuka operator client. Komponen yang Web Server Windows Server 2003 SP2 Web Client <<internet>> Browser support javascript Web Server IIS 6 * 1 .Net Framework 2.0 <<File>> Simak Web Site (ekstensi .aspx) <<Lan>> 1 1 Application Server Windows Server 2003 SP2 Operator Client Sistem Operasi Windows XP SP2 .Net Framework 2.0 .Net Framework 2.0 <<Lan>> * UDDI Server 1 Web Server IIS 6 <<File>> Simak Web Service (ekstensi .asmx) <<Executable>> SimakOptUI.exe <<Lan>> 1 1 Database Server Windows Server 2003 SP2 SQL Server 2005 .Net Framework 2.0 <<File>> Penyedia data web service (ekstensi .asmx) Gambar 11 Deployment diagram. Perancangan Antarmuka Antarmuka operator client merupakan aplikasi multiple document interface (MDI). Aplikasi memiliki jendela utama yang dapat menampung banyak jendela anak. Jendela utama memiliki tombol navigasi untuk menampilkan maupun menutup jendela anak. Satu jendela anak menampilkan domain data tertentu beserta data domain lain sebagai pelengkap. Sebagai contoh jendela anak untuk data mahasiswa, SPP, KRS. Setiap jendela anak memiliki tombol untuk melakukan operasi terhadap data, seperti pencarian, penghapusan, penambahan, dan pengubahan data. Antarmuka sistem dalam bentuk halaman web mengandung header, menu, dan bagian untuk menampilkan data secara tabular. Menu operasi antara antarmuka operator client dan antarmuka web berbeda karena disesuaikan dengan use case bagi setiap pengguna. Sebelum pengguna memasuki jendela atau halaman utama, pengguna harus memberikan identitas dan password pengguna. Antarmuka operator client digambarkan pada Gambar 12 sedangkan halaman web digambarkan pada Gambar 13. 13 Menu Utama Menu pada jendela anak Menu pada jendela anak Jendela anak Jendela anak Gambar 12 Perancangan antarmuka operator client . Header Menu operasi Tempat menampilkan hasil operasi Gambar 13 Perancangan halaman web. Penanganan Kesalahan Kesalahan atau error dapat terjadi pada lapisan data provider, business service, maupun user interface. Kesalahan yang muncul pada lapisan data provider seringkali disebabkan oleh interaksi yang tidak tepat antara aplikasi dengan basis data, sebagai contoh aplikasi mengakses database server yang tidak sedang berjalan. Kesalahan pada lapisan user interface sering muncul saat kelas pada lapisan user interface melakukan proses binding terhadap service. Kelas pada lapisan data provider harus memiliki mekanisme penanganan error tatkala berinteraksi dengan basis data dan kelas pada lapisan user interface harus memiliki mekanisme penanganan error saat binding service. Implementasi Pada tahap implentasi, hasil yang didapat pada tahap perancangan diwujudkan melalui pembuatan kelas dengan barisan kode yang dapat dieksekusi oleh .Net Framework. Kelas pada lapisan data provider, business service, dan user interface dibuat melalui project yang berbeda dalam Visual Studio.Net namun dalam satu solution. Pemisahan project berdasarkan perbedaan lapisan memberi kemudahan dalam perawatan sistem, seperti upaya update fitur maupun pengubahan layout antarmuka. Typed Dataset Dataset berisi tabel-tabel data yang menyimpan data yang digunakan dalam aplikasi secara sementara. Data dalam basis data dapat dimuat dalam dataset sehingga data tersedia bagi aplikasi dalam memori lokal. Aplikasi dapat bekerja dengan data dalam dataset sekalipun koneksi dengan basis data terputus. Pembuatan typed dataset dapat menyimpan informasi basis data yang digunakan, seperti tabel, kolom, relasi,dan stored procedure. Dataset termasuk lapisan data provider dan berbagai kelas dalam lapisan tersebut yang menggunakannya secara langsung. Pembuatan Pustaka Kelas Pembuatan pustaka kelas dapat meningkatkan cohesion dalam aplikasi. Kelas pada lapisan data provider dan business service serta tipe data enumeration dibuat dalam satu project dan dikompilasi bersama menjadi sebuah file pustaka kelas. Pustaka kelas ini digunakan untuk mengeksekusi proses bisnis yang diinginkan, seperti mengubah data mahasiswa dan mencetak transkrip nilai. Pembuatan Komponen Service Komponen service berfungsi menghasilkan web service sehingga fungsionalitas pada sistem dapat diakses oleh lapisan user interface sistem maupun lain. Pembuatan komponen service dilakukan dalam project tersendiri dan memiliki referensi pada pustaka kelas sebab pustaka kelas merupakan komponen yang mengeksekusi proses bisnis. Seluruh web service dibuat dalam satu komponen service untuk meminimalkan ketergantungan antarkomponen dalam aplikasi. Setiap pembuatan web service dalam komponen service dilakukan dengan pembuatan web method. Penanganan Kegagalan SOAP Serialization oleh Interface ICollection Setiap data hasil eksekusi suatu proses bisnis akan dikonversi oleh komponen service menjadi dokumen SOAP yang dapat dieksekusi oleh sistem atau mesin lain. Data hasil eksekusi dapat diberikan kepada web service client dengan melewatkan suatu objek dalam web method. Web service dapat menghasilkan data tunggal maupun tidak, namun permasalahan muncul tatkala web method harus melewatkan objek yang merupakan turunan kelas CollectionBase yang menggunakan interface ICollection. Komponen service dalam .Net Framework hanya dapat menghasilkan SOAP dari objek 14 yang tidak menjadi CollectionBase. turunan kelas Untuk memecahkan masalah tersebut, web method yang mengembalikan banyak data tidak melewatkan objek turunan kelas CollectionBase namun array yang berisi tipe data struktur. Struktur didefinisikan menurut data yang dieksekusi dan diinisialisasi dalam controller kelas. Sebagai contoh, jika web service harus mengembalikan banyak data mahasiswa, maka web method akan mengembalikan array StrukMahasiswa yang diinisialisasi oleh kelas MahasiswaManager. Publikasi Web Service Web service harus dipublikasikan sehingga dapat ditemukembalikan oleh subsistem atau entitas di luar sistem. Temukembali web service merupakan langkah awal untuk proses binding. Publikasi web service dilakukan melalui UDDI Server. Informasi yang harus diberikan sebagai masukan UDDI server meliputi service provider, contact information, dan access point yang merupakan alamat URL tempat web service berada. Bagian service provider berisi informasi yang terkait organisasi atau lembaga yang mempublikasikan service, misal nama organisasi dan kategori bidang usaha. Bagian contact information berisi informasi bagi web service client untuk menghubungi pihak yang mempublikasikan web service, misal alamat dan nomor telepon. Alamat URL pada bagian Access point menunjuk pada direktori dimana dokumen WSDL disimpan. Alamat URL memungkinkan WSDL dapat dilihat langsung web service client melalui web browser. Pembuatan Lapisan User Interface Pembuatan antarmuka pengguna meliputi project untuk antarmuka operator client dan web site. Kedua project memiliki referensi kepada web service sesuai access point yang ditunjukkan UDDI server. Pembuatan antarmuka operator client dilakukan dengan membuat beberapa kelas turunan System.Windows.Forms.Form dalam .Net Framework. Satu kelas ditentukan sebagai parent window yang dapat menampung kelas lain sebagai child window. Pembuatan antarmuka berbasis web dilakukan dengan membuat beberapa kelas turunan System.Web.UI.Page dalam .Net Framework. Kelas yang dibuat dalam kedua project menginisialisasi komponen-komponen visual yang telah ada dalam .Net Framework sesuai perancangan antarmuka. Penanganan Kesalahan Dalam .Net Framework terdapat pernyataan digunakan untuk menangkap berbagai kelas berfungsi menunjukkan eksepsi. Pernyataan tersebut adalah Try…Catch…Finally. Pernyataan ini dipakai untuk menangkap eksepsi saat berbagai kelas dalam lapisan data provider berusaha bekerja dengan basis data dan berbagai kelas dalam lapisan user interface berusaha menginisialiasasi web service. Gambar 14 adalah contoh potongan kode yang menunjukkan penggunaan pernyataan Try…Catch…Finally dalam suatu kelas untuk menangkap eksepsi yang muncul pada service binding. Dim SimakServ As SimakIpbService.Service = New SimakIpbService.Service Try If SimakServ.PeriksaKelengkapanSyaratWisuda(Me.TextBox1.Text) = True Then Me.lblStatus.Text = "Status : Syarat Wisuda telah Terpernuhi" Else Me.lblStatus.Text = "..." + ControlChars.NewLine + "..." End If Catch ex As Exception MsgBox("Server mati", MsgBoxStyle.Information, "Peringatan") End Try Gambar 14 Contoh penggunaan try…catch…finally. Keunggulan Sistem Sistem menyediakan fungsionalitasnya dalam bentuk service yang dapat digunakan sistem lain. Sistem juga dapat menggunakan service yang telah disediakan oleh sistem lain. Hal ini menunjukkan sistem memiliki kemampuan interoperability sekaligus dapat diintegrasikan dengan sistem lain. Contoh 15 pemakaian service sistem informasi akademik adalah ketika diperlukan pemeriksaan seorang mahasiswa apakah telah memenuhi syarat wisuda. Sistem di perpustakaan dapat mengonsumsi service yang memberikan data mahasiswa untuk pemeriksaan syarat bebas pustaka. Jika mahasiswa dinyatakan bebas pustaka, bukti elektronik dapat diberikan kepada sistem informasi akademik dalam bentuk service. Hal ini lebih handal dan cepat daripada pemrosesan secara manual. Pengujian Pengujian sistem dibagi menjadi dua, yaitu pengujian fungsionalitas web service dan pengujian interoperability. Pengujian fungsionalitas web service dilakukan dengan metode black box melalui antarmuka operator client dan web site. Pengujian interoperability dilakukan dengan pembuatan web service lain dengan lingkungan pengembangan yang berbeda, yaitu PHP dan web server Apache untuk dikonsumsi oleh web service sistem informasi akademik seperti pada Gambar 15. Sistem Untuk Uji Introperability Windows XP SP2 Apache 2 MySql 5 Simak Server service Windows Server 2003 SQL Server 2005 penelitian selanjutnya integrasi sistem informasi akademik dengan sistem lain dalam satu lingkungan universitas dapat dilakukan untuk meningkatkan efisiensi dan integritas data dan untuk mewujudkan proses bisnis yang lebih komprehensif. Penerapan protokol keamanan web service pada sistem informasi akademik dapat menjadi topik penelitian dengan memanfaatkan hasil penelitian ini. Salah satu penelitian yang dapat dilakukan adalah penerapan Security Assertion Markup Language (SAML) pada sistem informasi akademik dengan memperhatikan kebutuhan service berbagai unit/entitas dalam institusi pendidikan. DAFTAR PUSTAKA Hadiwinata, Mario. 2003. XML Web Service dengan Visual Basic.Net. Jakarta: Elex Media Komputindo. Koolwaij, et al. 2002. The Promise of Web Service an Analysis. https://doc.telin.nl/dscgi/ds.py/Get/File27842 [7 November 2006] Manes, A.T. 2003. Web Services A Manager’s Guide. USA: Addison-Wesley. IIS 6 PHP 5 Gambar 15 Pengujian interoperability. KESIMPULAN DAN SARAN Kesimpulan SOA dapat diterapkan dalam sistem informasi akademik. Fungsionalitas sistem disajikan dalam bentuk service yang dapat dikonsumsi sistem lain. Web service sistem juga dapat mengonsumsi web service dari sistem lain. Hal ini mengindikasikan interoperability telah tercapai. Strategi tertentu perlu digunakan untuk mengembalikan data dalam web service tergantung pada data yang dikembalikan. Tidak semua objek yang dihasilkan dari lingkungan pengembangan dapat dikonversi menjadi SOAP yang merupakan protokol standar pertukaran data. Salah satu strategi yang bisa ditempuh adalah mengembalikan array dari struktur yang berisi data objek yang tidak dapat dikonversi. Saran Sistem yang telah dikembangkan telah memenuhi kemampuan interoperability yang menjadi dasar upaya integrasi sistem. Pada Menasce DA, Almeida VAF. 2002. Capacity Planning for Web Service Metrics, Models, and Methods. Upper Saddle River New Jersey: Prentice Hall PTR. Pressman, R.S. 2001. Software Engineering: A Practitioner’s Approach. Fifth Edition. New York,USA: McGraw Hill. Sprott D, Wilkes L. 2004. Understanding Service Oriented Architecture. 10:17. [Microsoft Architect Journals]. http://www.architecturejournal.net/200 4/issue1/pdf/journal1_english.pdf [7 November 2006] Turban, et al. 2005. Introduction to Information Technology. USA: John Wiley & Sons, Inc. [W3C] World Wide Web Consortium. 2004. Web Service Architecture http://www.w3.org/TR/ws-arch/ [15 Juli 2006]
