BAB IV STUDI KASUS
Sesuai dengan hasil studi dan analisis mengenai konsep SOA, komponen-komponen BPMS, dan penerapannya pada Bab 2, selanjutnya dipilih sebuah studi kasus untuk menguji hasil analisis tersebut. Studi kasus yang dipilih adalah Virtual Research Center (VRC). VRC merupakan sebuah perangkat lunak yang berfungsi untuk mendukung penjalanan riset di dalam organisasi yang berupa pusat penelitian. Istilah VRC sendiri diambil dari [LAN06] yang menjelaskan mengenai perangkat lunak tersebut di Pusat Penelitian Teknologi Informasi dan Komunikasi Institut Teknologi Bandung. Oleh karena itu dalam mengambil studi kasus ini definisi dan kebutuhan perangkat lunak akan diambil berdasarkan yang ditulis pada [LAN06].
4.1 Deskripsi Umum Sistem 4.1.1 Deskripsi Umum VRC adalah sebuah perangkat lunak yang berfungsi sebagai digitalisasi pusat penelitian. VRC berfungsi membantu jalannya sistem dalam pusat penelitian. Adapun pihak-pihak yang terlibat dalam sistem ini adalah Ketua Pusat Penelitian (PP), Peneliti, Dekan, Ketua Kelompok Keahlian (KK), Reviewer, Sponsor, dan Publik. Peneliti adalah seorang atau kelompok peneliti yang mengadakan penelitian dengan difasilitasi oleh Ketua PP. Dekan dan Ketua KK berperan untuk menyetujui setiap proposal penelitian yang diajukan oleh peneliti. Reviewer merupakan pihak yang dipilih oleh Ketua Pusat Penelitian untuk memeriksa setiap proposal yang masuk apakah layak untuk diteliti. Sponsor adalah pihak yang mendanai setiap penelitian yang dilakukan oleh pusat penelitian. Kebutuhan sistem ini adalah sebagai berikut [LAN06]: 1
Pengelolaan Program Penelitian. Pusat Penelitian memiliki beberapa program penelitian, oleh karena itu, pada sistem ini dimungkinkan untuk mendefinisikan program penelitian, pengiriman proposal oleh peneliti, proses review proposal dari peneliti, penandatanganan perjanjian kontrak kerja, serta pemantauan dan evaluasi program penelitian yang sedang berjalan.
2
Fungsi Layanan Informasi. Sistem ini akan memberikan informasi melalui web terkait dengan pusat penelitian. Informasi tersebut terkait dengan berita, informasi peneliti, dan informasi penelitian. Sistem ini menyediakan fungsi untuk mengelola
IV-1
IV-2 informasi tersebut. 3
Fungsi Pengelolaan Pengguna Sistem VRC. Seluruh pengguna dari sistem VRC akan dapat dikelola oleh sistem ini oleh seorang administrator. Selain itu, setiap pengguna sistem ini dapat juga mengelola informasi yang terkait dengan dirinya.
4
Fungsi Pengelolaan Situs Pusat Penelitian. Kebutuhan dari pengelolaan situs adalah kemampuan untuk mengubah tampilan situs Pusat Penelitian dan adanya log untuk setiap transaksi pengubahan data yang terkait dengan program penelitian.
Dalam studi kasus ini, akan dibangun VRC sebagai sebuah perangkat lunak dengan menggunakan model penerapan BPM dan SOA. Namun, studi kasus yang diambil tidak mencakup keseluruhan sistem, melainkan dibatasi pada bagian-bagian yang terkait pada pembuatan Request For Proposal (RFP) dan proses pengiriman proposal untuk RFP tersebut sehingga akhirnya menjadi sebuah penelitian. Dikarenakan pembangunan studi kasus ini menggunakan model penerapan BPM pada SOA, maka akan digunakan metodologi pembangunan seperti yang telah dijelaskan pada Bab 3.3. Ada dua bagian analisis dan perancangan yang dilakukan, masing-masing untuk service dan perangkat lunak client.
4.1.2 Proses Bisnis Dalam studi kasus ini, akan diambil sebuah proses bisnis dari Pusat Penelitian yaitu pengajuan proposal. Proses pengajuan proposal ini adalah pengiriman proposal yang dilakukan peneliti kepada Ketua Pusat Penelitian untuk melakukan penelitian. Pengiriman proposal ini dilakukan dengan mengacu pada RFP yang ada saat itu. Jika terdapat sebuah RFP, maka peneliti berhak mengajukan proposal untuk penelitian sesuai kriteria yang telah ditentukan di RFP tersebut. Adapun proses pengajuan proposal tersebut dapat dilihat sebagai pada Gambar IV-1. Berdasarkan Gambar IV-1 dapat dilihat bahwa proses dimulai dari pengajuan proposal dari peneliti. Proposal tersebut lalu diproses sesuai jalur yang telah didefinisikan pada RFP. Ada jalur yang membutuhkan persetujuan Ketua KK atau Dekan atau keduanya terlebih dahulu sebelum diajukan ke Ketua Pusat Penelitian, ada pula yang langsung ke Ketua PP. Jika proposal disetujui, maka proses akan dilanjutkan ke pemilihan reviewer oleh Ketua Pusat Penelitian. Jika reviewer menerima, ia akan memberikan review terhadap proposal tersebut. Hasil review akan menjadi pertimbangan Ketua Pusat Penelitian untuk menyetujui proposal tersebut. Jika reviewer telah memberikan review dan proposalnya disetujui Ketua PP, maka tahap selanjutnya adalah negosiasi dana. Jika dana penelitian dapat disepakati, maka penelitian dapat dimulai.
IV-3
Gambar IV-1 Proses Bisnis Pengajuan Proposal
IV-4
4.2 Kebutuhan Perangkat Lunak 4.2.1 Fitur Perangkat Lunak Daftar kebutuhan fungsional yang akan diimplementasi oleh perangkat lunak dalam studi kasus ini dapat dilihat pada Tabel IV-1. Daftar kebutuhan fungsional ini dibutuhkan untuk mengimplementasikan proses bisnis pengajuan proposal seperti di Bab 4.1.2. Tabel IV-1 Kebutuhan Fungsional Virtual Research Center
SRS Fungsional
Keterangan
SRS-F-01
Pengelolaan request for proposal (RFP), meliputi pembuatan RFP, modifikasi informasi RFP, penghapusan RFP, dan melihat RFP yang ada.
SRS-F-02
Pengelolaan proposal, yaitu peneliti dapat mengajukan proposal jika terdapat RFP dalam suatu program penelitian dan melihat status proposal saat ini,
SRS-F-03
Persetujuan proposal, yaitu proposal dapat disetujui oleh ketua KK, dekan, dan Ketua PP
SRS-F-04
Pemilihan reviewer, yaitu Ketua PP dapat memilih reviewer untuk memberi review pada proposal
SRS-F-05
Persetujuan review, yaitu reviewer dapat memilih untuk menyetujui untuk memberikan review terhadap proposal atau tidak.
SRS-F-06
Review proposal, yaitu proposal dapat di-review oleh reviewer untuk selanjutnya diajukan kepada Ketua PP
SRS-F-07
Negosiasi dana, yaitu perangkat lunak memfasilitasi negosiasi dana antara peneliti dan Ketua PP
SRS-F-08
Pembukaan penelitian, yaitu Ketua PP dapat membuka sebuah penelitian baru jika proposal sudah disetujui
4.2.2 Pemodelan Kebutuhan Perangkat Lunak Untuk memberikan gambaran lebih jelas mengenai fungsi yang disediakan oleh perangkat lunak, maka akan dilakukan pemodelan perangkat lunak. Pemodelan ini akan ditunjukkan dalam pemodelan fungsional, dalam bentuk diagram use case. Pemodelan fungsional ini nantinya juga akan menghasilkan skenario yang akan menjadi pedoman untuk pembuatan diagram interaksi elemen pada perancangan perangkat lunak, yang nantinya akan menghasilkan kelas-kelas perancangan perangkat lunak. Diagram use case dari perangkat lunak ini dapat dilihat pada Gambar IV-2.
IV-5
Gambar IV-2 Use Case Diagram Untuk VRC
4.3 Analisis Service Salah satu tahapan dalam pembangunan perangkat lunak pada studi kasus ini adalah analisis service. Pada analisis service, dihasilkan sekumpulan kandidat service beserta operasinya. Untuk menghasilkan kandidat service ini, terlebih dahulu akan dilakukan identifikasi terhadap proses bisnis yang berjalan di sistem, identifikasi kandidat service, dan identifikasi operasi service. Identifikasi proses bisnis telah dilakukan sebelumnya pada Bab 4.1.2. Maka dari itu selanjutnya akan ditunjukkan identifikasi kandidat service dan operasi service.
4.3.1 Identifikasi Kandidat Service Identifikasi service dilakukan dengan pendekatan entity-centric, dikarenakan pendekatan ini akan menghasilkan perangkat lunak yang lebih moduler. Oleh karena itu, dilakukan analisis terhadap entitas-entitas apa saja yang ada di dalam sistem ini beserta keterhubungannya. Hasil analisis tersebut pada studi kasus ini diperoleh entitas-entitas yang terkait untuk mengimplementasikan kedua proses bisnis sebagai berikut : 1. Entitas User, yang mewakili pengguna sistem secara keseluruhan. 2. Entitas RFP, yang mewakili request for proposal. 3. Entitas Proposal, yang mewakili proposal dan segala propertinya 4. Entitas Research, yang mewakili penelitian. Keempat entitas tersebut akan menjadi empat buah service yang mewakili proses bisnis dari VRC. Dikarenakan mewakili proses bisnis, maka keempat service ini secara lojik akan berada pada business service layer. Selain empat service yang telah ditemukan di atas, diperlukan sebuah service tambahan untuk menangani manajemen file. Pada proses bisnis pengajuan proposal, manajemen file dibutuhkan untuk melakukan upload dan menyimpan file proposal. Proses manajemen file ini
IV-6 sebaiknya terpisah dari service proposal karena manajemen file merupakan sebuah fungsi yang bersifat generik. Dikarenakan service ini terkait dengan aplikasi, bukan proses bisnis, maka secara lojik ia akan berada pada application service layer. Selain itu, diperlukan sebuah service pada orchestration service layer. Service tersebut adalah Submit Proposal Service. Service inilah yang akan dipanggil oleh aplikasi client saat pengajuan proposal. Jadi, dari proses identifikasi ini, diperoleh enam buah kandidat service, yaitu Submit Proposal Service, User Service, RFP Service, Proposal Service, Research Service, dan File Management Service. Ilustrasi dari kandidat service yang dihasilkan dari tahap ini dapat dilihat pada Gambar IV-3.
Gambar IV-3 Hasil Identifikasi Kandidat Service
4.3.2 Identifikasi Operasi Service Identifikasi operasi dilakukan berdasarkan identifikasi proses bisnis, yaitu dengan melihat fungsi-fungsi apa saja yang dibutuhkan oleh proses bisnis tersebut agar bisa berjalan. Selain itu, juga dilakukan penambahan operasi-operasi tertentu yang mendukung proses bisnis itu namun berada di luar proses bisnis. Salah satu contohnya di sini adalah ketersediaan operasi untuk menambah, mengurangi, dan menghapus RFP. Penambahan ini juga dilakukan dengan melihat kebutuhan dari client, setelah analisis kebutuhan client dilakukan dan dilanjutkan oleh pembangunan service pada iterasi berikutnya. Hasil identifikasi operasi service yang diperoleh dapat dilihat padaTabel IV-2. Keterhubungan antara SRS, Service, dan operasi dapat dilihat pada Tabel IV-3.
IV-7 Tabel IV-2 Hasil Identifikasi Operasi Service
No
Service
S-01 S-02 S-03 S-04 S-05
Submit Proposal User RFP Research Proposal
S-06
File Management
Operasi • • • • • • • • • • • • • •
Ajukan Proposal Ambil Daftar Reviewer Ambil Jalur Proposal Buka Research Kirim Proposal kepada KK Kirim Proposal kepada Dekan Kirim Proposal kepada Ketua PP Kirim Tawaran Review kepada Reviewer Kirim Kesediaan Review ke Ketua PP Kirim Hasil review kepada Ketua PP Kirim Tawaran Dana kepada Peneliti Kirim Tawaran Dana ke Ketua PP Kirim Persetujuan ke Ketua PP Upload File
Tabel IV-3 Keterhubungan SRS, Use Case, dan Service
SRS
Use Case
Service
SRS-F-01
UC-01
S-03
SRS-F-02
UC-07, UC-08
S-01,S-05
SRS-F-03
UC-10
S-01, S-02, S-05
SRS-F-04
UC-02
S-01, S-02, S-05
SRS-F-05
UC-05
S-01, S-02, S-05
SRS-F-06
UC-06
S-01, S-02, S-05
SRS-F-07
UC-03, UC-09
S-01, S-02, S-05
SRS-F-08
UC-04
S-04
4.4 Perancangan Service Tahap berikutnya adalah perancangan service. Perancangan service merupakan dasar untuk melakukan pembangunan seluruh service untuk sistem. Pada perancangan ini, terlebih dahulu ditetapkan pemilihan teknologi yang digunakan untuk implementasi setiap service, lalu akan dilakukan identifikasi lebih lanjut mengenai operasi service. Selanjutnya untuk setiap service akan dilakukan identifikasi kelas perancangan, perancangan representasi persisten kelas entity jika menggunakan basis data, perancangan proses bisnis, dan pembuatan deployment diagram. Proses perancangan service ini berlangsung secara iteratif bersamaan dengan perancangan perangkat lunak client, yang umumnya terus menambahkan operasi pada service yang ada. Namun pada uraian di bawah, hanya dijelaskan hasil akhir dari identifikasi operasi service.
IV-8
4.4.1 Pemilihan Teknologi pada Service Secara lojik, keenam service yang telah diidentifikasi sebelumnya berada pada tiga lapisan. Seluruh service tersebut mengimplementasikan model yang telah didefinisikan pada Bab 3, yaitu model arsitektur yang memiliki lapisan orkestrasi, fungsi bisnis, dan aplikasi. Adapun pemilihan teknologi untuk setiap lapisan tersebut dijelaskan sebagai berikut. 1. Service pada lapisan orkestrasi diimplementasikan dengan menggunakan teknologi WS-BPEL. Service tersebut dideskripsikan dengan bahasa BPEL dan akan dijalankan dengan komponen process execution pada BPMS. 2. Service pada lapisan fungsi bisnis akan diimplementasikan menjadi sebuah web service dengan teknologi JAX-WS pada Java. 3. Service pada lapisan aplikasi, yakni File Management, akan diimplementasikan menjadi web service, namun akan menggunakan pilihan teknologi yang berbeda, yaitu PHP. Pemilihan ini didasarkan atas ketersediaan source code untuk menunjang web service ini dan sebagai simulasi bahwa arsitektur ini mampu berjalan di atas teknologi yang berbeda-beda. Untuk pembangunan BPEL, akan digunakan kakas process designer dari Intalio, seperti hasil analisis pada Bab 3. Untuk menggunakan kakas ini proses bisnis terlebih dahulu akan didefinisikan dalam bentuk format Business Process Modeling Notation (BPMN), yang selanjutnya akan membangkitkan. kode BPEL proses tersebut. Penjelasan lebih lanjut mengenai pembuatan proses bisnis ini dapat dilihat pada Bab 4.4.2.
4.4.2 Perancangan Proses Bisnis Seperti telah dijelaskan sebelumnya, proses bisnis akan didefinisikan dengan menggunakan teknologi WS-BPEL. Kode BPEL ini akan dibangkitkan menggunakan kakas process designer dari BPMS yang digunakan. Proses bisnis satu-satunya dalam studi kasus ini, yakni proses bisnis pengajuan proposal, melibatkan banyak pengguna. Proses tersebut hanya bisa terus berlangsung jika pengguna yang bertanggung jawab meneruskannya. Misalnya, proposal tidak dapat diproses oleh Ketua Pusat Penelitian jika belum disetujui Dekan dan alur proposal tersebut melalui dekan. Akan tetapi kakas Intalio BPMS yang digunakan tidak mendukung proses seperti itu. Oleh karena itu, proses bisnis pengajuan proposal tersebut harus dipecah menjadi sepuluh proses. Jumlah proses tersebut diambil berdasarkan jumlah kemungkinan masukan oleh pengguna. Ada sepuluh kemungkinan masukan dalam proses tersebut, sehingga dihasilkan sepuluh subproses. Kesepuluh proses tersebut dapat dilihat pada tabel Tabel IV-4.
IV-9 Tabel IV-4 Daftar Proses untuk Pengajuan Proposal No
Nama Proses
Deskripsi
1
SubmitProposal
Menangani pengiriman proposal dari peneliti ke Ketua PP, memilih jalur sesuai dengan data RFP
2
DekanApproval
Menangani persetujuan dekan dan meneruskan proposal sesuai jalurnya
3
KetuaKKApproval
Menangani persetujuan ketua KK dan meneruskan proposal sesuai jalurnya
4
PPApproval
Menangani persetujuan Ketua PP untuk melanjutkan proposal ke tahap selanjutnya
5
ChooseReviewer
Menangani pemilihan reviewer untuk proposal tertentu
6
ReviewerApproval
Menangani pilihan reviewer untuk memilih setuju mereview atau tidak
7
SubmitReview
Menangani pengiriman review dari reviewer ke Ketua PP
8
PPOfferBudget
Menangani penawaran dana oleh Ketua PP ke peneliti untuk sebuah penelitian yang telah disetujui
9
PenelitiApproval
Menangani pilihan peneliti untuk menyetujui, menolak atau menawar tawaran dana
10
OpenResearch
Menangani pembukaan penelitian baru oleh Ketua PP, yang menandakan penelitian dapat mulai berjalan.
Pada Gambar IV-4 diperlihatkan contoh pendefinisian proses SubmitProposal dalam BPMN.
Gambar IV-4 Proses SubmitProposal dalam BPMN
Proses ini jika dibangkitkan oleh process designer akan menghasilkan kode BPEL ada pada Lampiran B. Pendefinisian proses lainnya dalam BPMN dapat dilihat pada Lampiran A
IV-10
4.4.3 Identifikasi Operasi Service Berikut hasil identifikasi operasi service beserta padanannya dengan operasi yang didapatkan dari hasil analisis. Seluruh operasi tersebut dapat dilihat pada Tabel IV-5. Tabel IV-5 Daftar Identifikasi Operasi Service No
Nama Service
1 2 3 4 5 6 7 8 9 10 11
SubmitProposal DekanApproval KetuaKKApproval PPApproval ChooseReviewer ReviewerApproval SubmitReview PPOfferBudget PenelitiApproval OpenResearch WSUser
12
WSRFP
13
WSResearch
14
WSProposal
Operasi submitProposal dekanApproval ketuaKKApproval ppApproval chooseReviewer reviewerApproval submitReview ppOfferBudget penelitiApproval openResearch validateLogin getUserData getUserPosition getUsernameinPosition createRFP editRFP deleteRFP getRFP* getAllRFP createResearch getResearch getResearchList getAllResearchList submitProposal
changeStatus**
getStatus getProposal getProposalList addReviewer changeReviewerStatus addReview addOffer
15
WSFileManagement
getOffer getOfferList setBudget getReview getReviewListUsername getReviewListID uploadFile
Operasi Analisis Ajukan Proposal Ajukan Proposal Ajukan Proposal Ajukan Proposal Ajukan Proposal Ajukan Proposal Ajukan Proposal Ajukan Proposal Ajukan Proposal Ajukan Proposal Ambil Daftar Reviewer Ambil Jalur Proposal Buka Research Kirim Proposal kepada KK Kirim Proposal kepada Dekan Kirim Proposal kepada PP Kirim Proposal kepada KK Kirim Proposal kepada Dekan Kirim Proposal kepada PP Kirim Persetujuan kepada PP Kirim Tawaran Review kepada Reviewer Kirim Kesediaan review kepada PP Kirim Tawaran dana kepada Peneliti Kirim Tawaran dana ke PP Kirim Tawaran Review kepada Reviewer Kirim Kesediaan review kepada PP Kirim Hasil review kepada PP Kirim Tawaran dana kepada Peneliti Kirim Tawaran dana ke PP Upload File
IV-11 Keterangan: *Pengambilan jalur proposal akan diwakilkan dengan operasi pengambilan data RFP (getRFP). **Pengiriman persetujuan dan penanganan alur proposal dijadikan berupa manajemen status proposal. Jadi proposal tidak secara fisik dikirimkan ke setiap pengguna, namun akan diubah statusnya saja. Proposal akan mencapai pengguna (Ketua KK, Dekan, dan PP) jika memiliki status tertentu.
Pada tabel di atas terdapat sejumlah operasi yang tidak memiliki padanan dengan operasi analisis. Operasi tersebut muncul disebabkan munculnya kebutuhan pada perancangan client dan tidak muncul pada analisis proses bisnis dan kebutuhan yang muncul saat mendefinisikan proses dalam BPEL.
4.4.4 Identifikasi Kelas Perancangan Berdasarkan kebutuhan analisis service yang dan identifikasi operasi service yang telah didefinisikan sebelumnya, dilakukan identifikasi kelas-kelas perancangan yang akan merepresentasikan seluruh service yang akan dibangun. Khusus service yang berada pada lapisan orkestrasi, tidak akan dilakukan pembangunan kelas. Hal ini disebabkan seluruh service tersebut didefinisikan dalam BPEL dan telah dijelaskan dalam 4.4.2. Pembangunan kelas ini akan didasarkan dengan penggunaan framework JAX-WS untuk web service yang dibangun pada Java (WSUser, WSRFP, WSProposal, dan WSResearch) dan penggunaan
Library
nuSOAP
untuk
pembangunan
web
service
dalam
PHP
(WSFileManagement). Untuk web service yang diimplementasi dalam Java, akan dibentuk tiga buah paket yaitu database, entitybeans, dan webservices. Ketiga paket tersebut dapat dilihat pada Gambar IV-5.
Gambar IV-5 Diagram Paket Perancangan Web Service dalam Java
Sementara
untuk
implementasi
web
service
dengan
menggunakan
PHP
pada
WSFileManagement tidak digunakan paket karena tidak ada dukungan untuk paket dalam PHP. Gambaran umum kelas perancangan yang dihasilkan dapat dilihat pada Tabel IV-6. Daftar kelas ini dibagi menjadi dua, yakni kelas perancangan untuk Java dan PHP.
IV-12 Tabel IV-6 Daftar Kelas Perancangan untuk Web Service No Nama Paket Nama Kelas Keterangan Kelas perancangan untuk implementasi web service dalam Java 1 database DBConnector Kelas untuk konektivitas ke basis data 2 entitybeans Proposal Kelas entitas untuk proposal RFP Kelas entitas untuk RFP Research Kelas entitas untuk Research Review Kelas entitas untuk Review User Kelas entitas untuk User Negotiation Kelas entitas untuk negosiasi dana 3 webservices WSProposal Kelas untuk web service WSProposal WSRFP Kelas untuk web service WSRFP WSResearch Kelas untuk web service WSResearch WSUser Kelas untuk web service WSUser Kelas perancangan untuk implementasi web service dalam PHP 1 WSFileManagement Kelas untuk web service WSFileManagement 2 File Library untuk penanganan file
Diagram kelas untuk seluruh kelas perancangan yang menggambarkan keterhubungan antar kelas dapat dilihat pada Gambar IV-6. Seperti digambarkan di sana, untuk pembangunan sebuah web service dibutuhkan sebuah kelas untuk web service, beberapa buah kelas entitas untuk mendefinisikan data, dan sebuah kelas yang menangani konektivitas ke basis data jika dibutuhkan. Misalnya seperti terlihat pada kelas web service WSProposal. Web service tersebut membutuhkan kelas WSProposal untuk mendefinisikan web service, kemudian kelas Proposal dan Review untuk mendefinisikan entitas yang digunakan oleh web service tersebut, dan setiap kelas entitas tersebut akan menggunakan kelas koneksi ke basis data jika dibutuhkan. Gambaran lebih detil mengenai seluruh kelas yang dirancang dapat dilihat pada Lampiran A Bab 3.4.
Gambar IV-6 Diagram Kelas Perancangan
IV-13
4.4.5 Perancangan Representasi Persisten Kelas Entity Dari daftar kelas perancangan yang dihasilkan pada Bab 4.4.4, dibutuhkan representasi persisten untuk kelas yang terdapat pada paket entitybeans. Representasi persisten tersebut diwujudkan dalam sekumpulan tabel pada basis data. Daftar tabel yang dirancang untuk implementasi representasi data tersebut dapat dilihat pada Tabel IV-7. Tabel IV-7 Representasi Persisten Kelas Entity No. 1. 2.
Nama Tabel posisi_user proposal
Nama Kelas Entity Proposal
3.
research
Research
4. 5.
review rfp
Review RFP
6.
user
User
7.
budgetnegotiation
Negotiation
Atribut username, posisi id, id_rfp, username,judul_proposal, periode_start, periode_finish, file_proposal, draft_budget, budget, waktu_masuk, status, downloaded, abstraksi, feedback id_research, id_ppict, nama_research, username_headproject, keterangan, closed, jumlah_term id, idprop, reviewer, status, review id, judul, for_public, jadwal, sponsor, total_dana, batas_biaya, pj, info_kontak, deskripsi, ketentuan_umum, syarat, deadline, file_detil, bidang_keilmuan username, password, fullname, gender, alamat, no_telp, no_hp, email, NIP_NIM, golongan, pangkat, univ_instansi, fak_sek, kk, gambar. negotiationid, proposalid, budget,type
Khusus untuk tabel posisi_user, tabel ini tidak merepresentasikan kelas entity, tapi dibutuhkan karena setiap pengguna (user) dapat memiliki lebih dari satu peran (misal: peneliti dan ketua KK). Sementara untuk kelas File tidak dilakukan penyimpanan ke basis data dikarenakan fungsinya menyimpan file di tempat fisik. Alamat penyimpanan sendiri akan berada pada entitas yang menggunakannya. Misalkan pada kasus ini, alamat file proposal akan disimpan pada atribut file_proposal pada tabel proposal. 4.4.5.1
Deployment Diagram
Rencana implementasi service dari VRC digambarkan seperti Gambar IV-7. Service yang diimplementasi dalam Java akan dijalankan oleh web server Sun Application Server dan web service yang diimplementasi dalam PHP akan dijalankan oleh web server Apache. Seluruh web service di Web server Sun Application Server akan menggunakan basis data MySQL menggunakan JDBC.
IV-14
Gambar IV-7 Deployment Diagram untuk Service pada VRC
4.5 Perancangan Client Pada bagian ini akan dilakukan perancangan perangkat lunak client dengan melihat pada analisis kebutuhan dan perancangan service yang dilakukan sebelumnya. Pada bagian ini akan dihasilkan identifikasi kelas perancangan dengan sebelumnya memodelkan sequence diagram perancangan berdasarkan skenario use case yang ada pada kebutuhan perangkat lunak. Selain itu, juga akan dibuat perancangan antarmuka dan deployment diagram. Perancangan perangkat lunak client dibangun berdasarkan teknologi JSP dan Servlet. Kombinasi kedua teknologi ini akan menghasilkan sebuah aplikasi web yang dinamis. Kelas perancangan akan dibuat berdasarkan teknologi Servlet dan antarmuka akan diirancang dengan JSP. Selain itu, dalam implementasi nantinya, aplikasi ini akan ditunjang oleh framework JAX-WS dari Java untuk pemanggilan web service yang digunakan. Framework ini akan menghasilkan kelas-kelas yang akan digunakan jika ingin memanggil operasi web service. Namun detil dari tiap kelas yang dihasilkan tidak akan dijelaskan pada bagian ini.
4.5.1 Pemodelan Aplikasi Client Untuk mempermudah penjelasan dan perancangan tentang fungsi aplikasi client maka akan diberikan pemodelan khusus aplikasi ini. Berikut pemodelan use case diagram untuk aplikasi client.
IV-15
Gambar IV-8 Diagram use case untuk client
Dari diagram use case tersebut terlihat bahwa aplikasi client akan terhubung dengan VRC Service, sebuah aktor yang melambangkan seluruh service yang telah dianalisis dan dirancang sebelumnya.
4.5.2 Identifikasi Kelas Perancangan Berdasarkan analisis kebutuhan yang dilakukan sebelumnya maka akan dirancang kelas-kelas yang akan merepresentasikan perangkat lunak ini. Seperti telah dijelaskan sebelumnya, kelaskelas perancangan ini dihasilkan dari pemodelan interaksi elemen (sequence diagram) yang mengacu pada skenario use case. Hasil identifikasi kelas perancangan ini menghasilkan tiga paket utama, yaitu paket servlet, refprocess, dan refservices. Setiap paket akan memiliki sejumlah paket lagi di dalamnya. Adapun ilustrasi dari paket-paket tersebut dapat dilihat pada Gambar IV-9 Diagram Paket untuk Client VRC
IV-16
Gambar IV-9 Diagram Paket untuk Client VRC
Paket servlets merupakan paket yang yang digunakan untuk membuat tampilan dan mengatur interaksi dengan user. Kelas-kelas yang berada di dalam subpaket ini akan menggunakan kelas-kelas yang terdapat dalam subpaket di dalam refprocess dan refservices. Kedua paket ini dan setiap subpaket di dalamnya ini berisikan kelas-kelas yang dibangkitkan oleh framework JAX-WS khusus untuk memanggil web service yang digunakan oleh aplikasi client. Setiap paket kelas akan dibangkitkan untuk sebuah web service. Adapun daftar web service yang digunakan dan paket yang dibangkitkan untuknya dapat dilihat pada lampiran A. Kelas perancangan yang bukan merupakan hasil pembangkitan adalah paket servlet dan setiap subpaket yang ada di dalamnya. Adapun daftar kelas perancangan tersebut beserta web service yang digunakan dapat dilihat pada Tabel IV-8. Tabel IV-8 Daftar Kelas Perancangan Client VRC dan Web Service yang Digunakan No 1
Nama Paket servlets
Nama Kelas Authentication Dashboard Logout Approval Negotiation Proposal RFP Research Review
Web Service yang Digunakan WSUser WSUser WSUser WSProposal, WSRFP, KetuaKKApproval, DekanApproval WSProposal, PPOfferBudget, PenelitiApproval WSProposal, WSRFP, SubmitProposal, WSRFP WSProposal, WSResearch, OpenResearch WSProposal,WSRFP, WSUser, ChooseReviewer, ReviewerApproval, SubmitReview, PPApproval
4.5.3 Perancangan Antarmuka Secara umum antarmuka dari client VRC dapat dilihat pada Gambar IV-10. Halaman akan terdiri atas tiga bagian yaitu banner, isi halaman, dan menu. Banner akan menampilkan judul
IV-17 dari perangkat lunak, dalam hal ini Virtual Research Center. Isi halaman berisi informasi atau form yang sedang aktif. Menu berisikan. Menu berisikan link yang mengacu kepada fitur-fitur perangkat lunak ini, termasuk untuk login dan logout. Bagian menu ini akan bersifat dinamik dan menyesuaikan dengan hak yang dimiliki oleh setiap pengguna.
Gambar IV-10 Perancangan Antarmuka
4.5.4 Deployment Diagram Rencana implementasi dari perangkat lunak client ini dapat dilihat pada Gambar IV-11. Perangkat lunak akan berjalan di atas web server Sun Application Server. Pengguna akan langsung mengakses aplikasi ini dari browser ke web server. Perangkat lunak client ini nantinya akan terhubung dengan service. Penjelasan mengenai hal tersebut akan digambarkan pada Bab 4.6.
Gambar IV-11 Deployment Diagram Client VRC
4.6 Deployment Diagram Keseluruhan Pada bab-bab sebelumnya telah digambarkan bagaimana deployment diagram untuk client dan service. Pada bagian ini, keseluruhan sistem dari VRC akan dapat dilihat pada deployment diagram keseluruhan yang melibatkan perangkat lunak client, service, dan BPMS dapat dilihat pada Gambar IV-12.
IV-18
Gambar IV-12 Deployment Diagram Keseluruhan
Dari gambar dapat dilihat bahwa pengguna mengakses sistem melalui browser. Akses dilakukan ke client VRC. Client VRC lalu memanggil proses dari Intalio BPMS Server atau langsung ke web service VRC. Proses yang dipanggil melalui Intalio BPMS Server akan memanggil web service yang ada. Saat dibutuhkan Web service ini nantinya akan menggunakan basis data dan web service yang dibangun dengan PHP (WSFileManagement) untuk menjalankan fungsinya.
