BAB IV STUDI KASUS

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.