BAB 4 ANALISIS DAN PERANCANGAN APLIKASI Dalam studi kasus ini akan dibangun 3 buah aplikasi, yaitu aplikasi pengelolaan transaksi penjualan (SIPOS) sebagai aplikasi utama yang berbasis SOA serta aplikasi pengelolaan data inventaris toko (SIBARANG) dan aplikasi pengelolaan data member (SIMEMBER) sebagai aplikasi pendukung yang berbasis web. Keterhubungan antara ketiga aplikasi ini adalah SIPOS akan berinteraksi dengan aplikasi SIMEMBER untuk melakukan update terhadap poin member dan aplikasi SIBARANG untuk melakukan update terhadap stok barang. Interaksi antara ketiga aplikasi ini dilakukan dengan teknologi web services. Aplikasi SIPOS akan dibuat berbasis SOA sedangkan SIMEMBER dan SIBARANG adalah aplikasi yang tidak berbasis SOA.
4.1 Aplikasi Pengelolaan Transaksi Penjualan (SIPOS) Aplikasi SIPOS adalah aplikasi yang menjadi topik utama dalam tugas akhir ini. Deskripsi dari aplikasi SIPOS terletak dalam subbab 3.2.1 dan untuk pembangunan aplikasi SIPOS dilakukan dengan mengkuti metodologi yang telah dibahas dalam subbab 3.1.
4.1.1 Identifikasi Business Process Dalam studi kasus ini, akan digunakan business process utama yang terjadi pada aplikasi transaksi penjualan, yaitu business process penjualan barang. Business process ini adalah kegiatan utama yang akan terjadi saat adanya suatu transaksi penjualan barang di toko. Business process ini dapat dilihat dalam gambar 4-1.
Business process penjualan barang dimulai dari kegiatan pelanggan menaruh barang belanjaan di kasir. Kasir akan melakukan pendataan terhadap barang belanjaan yang akan dibeli, untuk selanjutnya dimasukkan ke dalam aplikasi transaksi penjualan. Setelah memasukkan data transaksi dan barang-barang yang dibeli, kasir akan meminta nomor member pelanggan. Permintaan nomor member ini karena setiap member yang melakukan transaksi penjualan di toko tersebut akan mendapatkan poin apabila telah berbelanja dengan jumlah nominal tertentu. Nomor member berikut poin yang telah didapatkan member tersebut untuk transaksi yang sedang berlangsung selanjutnya akan dikirimkan ke aplikasi pengelolaan data member untuk dilakukan update terhadap data member yang ada di aplikasi tersebut. Data barang yang terjual pada transaksi yang sedang berlangsung akan dikirimkan ke aplikasi pengelolaan inventaris toko agar dapat dilakukan update terhadap data stok barang yang ada dalam aplikasi tersebut.
4-1
4-2
Gambar 4-1. Business Process Penjualan Barang 4.1.2 Pemodelan Kebutuhan Aplikasi 4.1.2.1
Fitur Aplikasi
Aplikasi transaksi penjualan yang akan dibangun akan memiliki fitur-fitur seperti ditunjukkan dalam daftar kebutuhan fungsional dalam Tabel 4-1. Fitur-fitur yang ada tersebut adalah untuk melakukan kegiatan dalam business process yang disebutkan dalam subbab 4.1.
4-3 Tabel 4-1. Daftar Kebutuhan Fungsional Aplikasi Transaksi Penjualan No. 1. 2. 3. 4.
SRS ID SRS-SIPOS-01 SRS-SIPOS-02 SRS-SIPOS-03 SRS-SIPOS-04
5.
SRS-SIPOS-05
4.1.2.2
Keterangan Penerimaan input nomor member dari kasir Pengelolaan data barang yang dijual Perhitungan poin hasil transaksi penjualan Melakukan penambahan terhadap poin member ke aplikasi pengelolaan data member Melakukan pengurangan stok barang ke aplikasi pengelolaan inventaris took
Model Use Case
Pemodelan kebutuhan aplikasi seperti dijelaskan dalam subbab 3.1 akan dibuat dalam bentuk use case model. Tujuan dilakukannya pemodelan kebutuhan aplikasi adalah untuk memperjelas gambaran yang ada mengenai kebutuhan aplikasi, terutama mengenai fitur, cara kerja, dan service yang kiranya harus disediakan oleh aplikasi.
Gambar 4-2 dibawah ini memperlihatkan use case diagram dari aplikasi transaksi penjualan. Aplikasi transaksi penjualan mempunyai 3 buah use case yang akan digunakan oleh 3 aktor. Pemilihan use case dan aktor didasarkan pada business process yang terdapat dalam subbab 4.1.1. Daftar dari use case dapat dilihat dalam Tabel 4-3 dan daftar aktor yang ada pada aplikasi transaksi penjualan dapat dilihat dalam Tabel 4-4.
Gambar 4-2. Use Case Diagram SIPOS
4-4 Gambar 4-2 menunjukkan gambaran mengenai use case yang dibuat dalam aplikasi pengelolaan transaksi penjualan (SIPOS). Akan ada seorang kasir yang akan menggunakan aplikasi ini, dan pengguna tersebut dapat melakukan kegiatan yang berkaitan dengan data transaksi penjualan seperti melakukan pengelolaan data transaksi penjualan yaitu memasukkan dan melihat data transaksi penjualan. Selain pengelolaan data transaksi penjualan yang dilakukan oleh kasir, aplikasi ini juga akan terhubung pada aplikasi pengelolaan inventaris untuk melakukan update terhadap stok barang yang ada dan terhubung pada aplikasi pengelolaan data member untuk melakukan penambahan poin member. Kedua hal tersebut dilakukan dengan cara melakukan akses terhadap layanan web services yang disediakan oleh aplikasi masing-masing.
Tabel 4-2 memuat definisi sebagian use case yang ada dalam aplikasi ini dan Tabel 4-3 memuat daftar sebagian aktor yang terlibat. Untuk lebih lengkapnya, dapat dilihat dalam dokumen teknis lampiran C subbab C.1.2.
Tabel 4-2. Tabel Use Case Aplikasi No. 1.
ID Use Case UC-SIPOS-01
Nama Mengelola penjualan
transaksi
Deskripsi Use case dimana transaksi penjualan yang terjadi mampu untuk ditambah dan dilihat
Tabel 4-3. Tabel Aktor Aplikasi No. 1.
ID Aktor AKT- SIPOS01
Nama Kasir
Deskripsi Aktor pengguna aplikasi transaksi penjualan, bertugas untuk memasukkan mengelola data transaksi penjualan serta memasukkan nomor member pelanggan
Contoh skenario untuk use case dapat dilihat di bawah ini. Untuk lebih lengkapnya, dapat dilihat dalam dokumen teknis bagian lampiran C subbab C.1.2.
Use case : UC-SIPOS-001 Mengelola transaksi penjualan Aktor : Kasir Prekondisi : Kasir telah masuk ke dalam sistem Skenario : Aksi Aktor Reaksi Sistem Skenario Normal : Kasir memasukkan data transaksi penjualan 1.Kasir memilih pilihan tambah data transaksi penjualan 2. Sistem menampilkan form untuk memasukkan data transaksi penjualan 3.Kasir memasukkan data transaksi penjualan
4.Sistem menyimpan data transaksi penjualan
4-5 Skenario Alternatif : Kasir melihat data transaksi penjualan yang ada 1. Kasir memilih pilihan lihat data transaksi penjualan 2. Sistem menampilkan data transaksi penjualan yang ada
4.1.3 Analisis Service Analisis service adalah tahapan selanjutnya dalam pengembangan aplikasi setelah dilakukannya identifikasi business process dan pemodelan kebutuhan aplikasi. Dalam tahapan analisis service ini, akan digunakan business process yang telah diidentifikasi sebelumnya dalam subbab 4.1.1. Kegiatan yang dilakukan dalam tahapan ini berupa analisis service dalam SOAD seperti disebutkan dalam subbab 2.2.1, akan tetapi yang dilakukan dalam tahap ini adalah kegiatan identifikasi kandidat service dan service operation. Kegiatan mendefinisikan kebutuhan bisnis dalam bentuk business process telah dilakukan dalam subbab 4.1.1. dan identifikasi sistem yang telah ada dimasukkan dalam model use case dalam subbab 4.1.2.
4.1.3.1
Identifikasi Kandidat Service
Identifikasi kandidat service dilakukan dalam setiap layer yang ada pada SOA seperti disebutkan dalam subbab 2.1.3, yaitu dalam application service layer, business service layer, dan orchestration service layer. Identifikasi kandidat service dilakukan berdasarkan kebutuhan yang telah didapatkan dari pemodelan kebutuhan aplikasi dalam subbab 4.1.2. serta business process dalam subbab 4.1.1.
A. Kandidat Service Business Service Layer Dalam business service layer, identifikasi dilakukan dengan cara melihat business process yang ada kemudian akan dilakukan identifikasi bagian-bagian yang akan dibuat sebagai kandidat service. Cara identifikasi kandidat service dalam layer ini dapat dilakukan dengan dua cara, yaitu entity-centric business service dan task-centric business service. Dalam mengidentifikasi task-centric business service selain menggunakan business process yang sudah ada, juga dilakukan identifikasi dari skenario use case yang dimiliki dibuat sebelumnya dalam use case model. Ada tiga kandidat entity-centric business service dan lima buah kandidat task-centric business service yang dihasilkan sehingga total ada delapan buah kandidat service yang akan ada dalam business service layer.
1.Entity-Centric Business Service Entity-centric business service dilakukan dengan cara melakukan identifikasi entity yang didapatkan dari business process. Hasil dari proses identifikasi ini memunculkan tiga buah entitas, yaitu sebagai berikut :
4-6 a. Transaksi, yaitu entitas transaksi penjualan barang yang memuat data-data transaksi penjualan barang di toko tersebut. b. Member, yaitu entitas yang memuat data member seperti nomor member dan poin. c. Barang, yaitu entitas yang memuat data barang seperti stok/jumlah dan harga barang. Ketiga entitas yaitu transaksi, member, dan barang masing-masing akan menjadi service dalam business service layer.
2.Task-Centric Business Service Task-centric business service didapatkan dengan memetakan langkah-langkah yang ada pada business process menjadi service. Dari 5 langkah yang ada business process dalam subbab 4.1.1 didapatkan 4 kandidat service. Hasil dari identifikasi ini dapat dilihat dalam Tabel 4-4.
Tabel 4-4. Pemetaan Business Process menjadi Kandidat Task-Centric Business Service No. 1. 2. 3. 4. 5.
Langkah dalam Business Process Pelanggan menaruh barang belanjaan di kasir Kasir memasukkan data barang yang dijual Kasir meminta nomor member pelanggan Tambahkan nilai poin ke data member pada aplikasi pengelolaan data member Update stok inventaris barang pada aplikasi pengelolaan inventaris toko
Kandidat Service Service memasukkan data transaksi Service memasukkan nomor member pelanggan Service penambahan poin member Service melakukan update stok inventaris stok
Selain dengan memetakan dari langkah business service yang ada, juga dilakukan pemetaan dari pemodelan use case yang telah dibuat dalam subbab 4.1.2.2. Hasil identifikasi dari pemodelan use case ini akan menghasilkan task-centric business service karena merupakan pemetaan dari sebuah kegiatan yang ada dalam sistem. Hasil dari identifikasi ini dapat dilihat dalam Tabel 4-5.
Tabel 4-5. Pemetaan Use Case menjadi Kandidat Task-Oriented Business Service No. 1.
Use Case Mengelola transaksi penjualan
2. 3.
Mengupdate stok inventaris barang Menambah poin member
Kandidat Service Service melihat data transaksi Service memasukkan data transaksi Service melakukan update stok inventaris toko Service penambahan poin member
Kedua jenis task-oriented business service yang didapatkan dari hasil identifikasi pada business process dan dari hasil identifikasi pada use case selanjutnya akan digabungkan karena ada yang beririsan satu sama lain sehingga hasil task-oriented business service yang dihasilkan ada lima buah service yang dijelaskan dalam Tabel 4-6.
4-7 Tabel 4-6. Kandidat Service Task-Oriented Business Process Final No.
1. 2. 3. 4. 5.
Kandidat Service Task Oriented Business Service dari Business Process Service memasukkan data transaksi -
Kandidat Service TaskOriented Business Service dari Use Case Service memasukkan data transaksi Service melihat data transaksi
Service memasukkan nomor member pelanggan Service penambahan poin member Service melakukan update stok inventaris stok
Service penambahan poin member Service melakukan update stok inventaris toko
Kandidat Service TaskOriented Business Service Akhir Service memasukkan data transaksi Service melihat data transaksi Service memasukkan nomor member pelanggan Service penambahan poin member Service melakukan update stok inventaris toko
B.Kandidat Service Application Service Layer Kandidat service dalam application service layer adalah application service, yaitu service yang dibutuhkan oleh aplikasi untuk menjalankan fungsi / kegiatan yang ada dalam business process. Dalam studi kasus ini, telah dilihat bahwa dibutuhkan sebuah service untuk mengatur manajemen data-data transaksi penjualan, member, dan barang dalam sebuah basis data. Service ini tidak termasuk dalam bagian business process karena merupakan fungsi teknis, yaitu fungsi yang berkaitan dengan teknis basis data aplikasi. Bagian ini harus ada dan tidak bisa dilepaskan dari aplikasi. Oleh karena itu diidentifikasi sebuah application service berupa service manajemen data yang akan terletak dalam application service layer.
C.Kandidat Service Orchestration Service Layer Kandidat service untuk orchestration service layer adalah service yang dilakukan untuk mengorkestrasi atau mengatur service yang ada pada layer-layer dibawahnya. Dari business process yang ada pada subbab 4.1.1, didapatkan bahwa businses process yang utama adalah business process melakukan transaksi yang terdiri dari meminta input transaksi, melakukan update terhadap poin member, dan melakukan update pada stok barang. Hal ini membuat dibutuhkannya sebuah service di orchestration layer yang nantinya akan mengatur serviceservice yang ada di bawahnya seperti melakukan update stok barang dan update poin member agar dapat berjalan sesuai urutan yang telah didapatkan. Service ini nantinya akan diinvokasi oleh aplikasi dengan pengguna yaitu kasir, dan karena merepresentasikan seluruh kegiatan dari business process melakukan transaksi maka akan diberi nama service melakukan transaksi. D.Kandidat Service Final Kandidat service yang telah diidentifikasi digabung sehingga menghasilkan 10 kandidat service seperti pada Gambar 4-3.
4-8
Gambar 4-3. Hasil Identifikasi Kandidat Service 4.1.3.2
Identifikasi Kandidat Service Operation
Identifikasi kandidat service operation dilakukan dengan melihat kandidat service yang telah diidentifikasi sebelumnya pada subbab 4.1.3.1 untuk selanjutnya diidentifikasi operasioperasi / kegiatan-kegiatan yang perlu dilakukan oleh service tersebut. Operasi dan kegiatan tiap service akan diperoleh berdasarkan business process yang terdapat dalam subbab 4.1.1.
Tabel 4-7. Daftar Kandidat Service dan Service Operation Service ID S-SIPOS-01
Jenis Service Process Service
Service Melakukan transaksi
Service Operation Input transaksi
S-SIPOS-02
Entity-Centric Business Service
Transaksi
Simpan transaksi
Lihat transaksi
S-SIPOS-03
Entity-Centric Business Service
Member
Kirim nomor member Hitung poin member
S-SIPOS-04
Entity-Centric Business Service
Barang
Hitung barang terjual
S-SIPOS-05
Task-Centric Business Service
Memasukkan data transaksi
Menyimpan Data Transaksi
Deskripsi Melakukan transaksi penjualan yang terjadi pada suatu waktu Menyimpan transaksi ke dalam basis data Melihat transaksi yang telah ada dalam basis data Mengirim nomor member Menghitung poin member yang didapatkan dalam suatu transaksi Menghitung jumlah barang terjual
Menyimpan transaksi penjualan yang terjadi pada suatu waktu
4-9 Tabel 4-7. Daftar Kandidat Service dan Service Operation (Lanjutan) Service ID S-SIPOS-06
Jenis Service Task-Centric Business Service
Service Melihat data transaksi
Service Operation Melihat data transaksi
S-SIPOS-07
Task-Centric Business Service
Memasukkan nomor member pelanggan
S-SIPOS-08
Task-Centric Business Service
Penambahan poin member
Memasukkan nomor member pelanggan Penambahan poin member
S-SIPOS-09
Task-Centric Business Service
Melakukan update stok inventaris toko
S-SIPOS-10
Application Service
Manajemen Basis Data
Melakukan update stok inventaris toko Akses data transaksi
Deskripsi Melihat transaksi yang telah ada dalam basis data Menerima input nomor member Menambah poin member dengan poin transaksi Melakukan update terhadap stok inventaris toko Mengakses basis data transaksi
Tabel 4-7 memuat daftar kandidat service dan service operation yang telah diidentifikasi. Total akan ada 10 service dengan 12 service operation yang diharapkan mampu untuk memenuhi kebutuhan yang telah disebutkan dalam pemodelan kebutuhan dan business process. Keterhubungan antara kandidat service dengan pemodelan kebutuhan akan disebutkan dalam Tabel 4-8.
Tabel 4-8. Daftar Keterhubungan SRS, Use Case, dan Service SRS ID SRS-SIPOS-01 SRS-SIPOS-02
Use Case ID UC-SIPOS-03 UC-SIPOS-01
SRS-SIPOS-03 SRS-SIPOS-04 SRS-SIPOS-05
UC-SIPOS-03 UC-SIPOS-03 UC-SIPOS-02
Service ID S-SIPOS-03, S-SIPOS-07 S-SIPOS-01, S-SIPOS-02, S-SIPOS-10, S-SIPOS-05, S-SIPOS-06 S-SIPOS-03 S-SIPOS-03, S-SIPOS-08 S-SIPOS-04, S-SIPOS-09
4.1.4 Perancangan Service Tahap berikutnya adalah perancangan service. Kegiatan yang dilakukan dalam tahapan ini berupa desain service dalam SOAD seperti disebutkan dalam subbab 2.2.2 pada gambar 211, akan tetapi yang dilakukan dalam tahap ini adalah kegiatan refinement kandidat service dan service operation hasil analisis dalam subbab 4.1.3.
menjadi service dan service
operation final. Kegiatan mengkomposisi SOA tidak dilakukan karena pendefinisian teknologi yang akan dipakai dalam SOA akan dilakukan dalam perancangan SCA, serta business process design tidak dilakukan karena dilihat business process hasil identifikasi dalam subbab 4.1.1 telah cukup menggambarkan logika yang ada dalam orchestration layer SOA.
4-10 4.1.4.1
Identifikasi Service
Dari hasil identifikasi kandidat service dalam subbab 4.3.3.1., didapatkan 10 buah kandidat service yaitu service memasukkan transaksi, transaksi, member, barang, memasukkan data transaksi, melihat data transaksi, memasukkan nomor member pelanggan, penambahan poin member, melakukan update stok inventaris toko, dan manajemen basis data. Refinement yang dilakukan adalah dengan menggabungkan kandidat service taskoriented business service dengan kandidat entity-oriented business service karena dilihat bahwa kandidat service task-oriented business service dapat dibuat menjadi sebuah service operation dari kandidat service entity-oriented business service. Dengan digabungkannya kandidat service task-oriented business service menjadi service operation dari kandidat service entity-oriented business service, maka jumlah service dapat dikurangi dan service operation akan mampu dikelompokkan serta service akan bersifat lebih modular.
Refinement lain yang dilakukan adalah dengan menggabungkan kandidat service memasukkan transaksi dengan service transaksi. Hal ini karena business service transaksi dianggap lebih cocok untuk digabungkan process service transaksi karena mengatur jalannya aplikasi secara keseluruhan. Selain kedua refinement tersebut tidak ada refinement lain yang dilakukan terhadap kandidat service pada tahap ini karena dilihat bahwa kandidat service yang telah cukup untuk mewakili business process dan kebutuhan aplikasi. Daftar akhir service dapat dilihat dalam Tabel 4-9.
Tabel 4-9. Daftar Service No. 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
Service Hasil Analisis Melakukan transaksi Transaksi Memasukkan data transaksi Melihat data transaksi Member Memasukkan nomor member pelanggan Penambahan poin member Barang Melakukan update stok inventaris toko Manajemen Basis Data
Service Hasil Desain Transaksi
Member
Barang
Manajemen basis data
Adanya service manajemen basis data
yang akan menangkap dan menyimpan data
berupa data transaksi dan data barang yang dijual dalam business process pada subbab 4.1.1 membuat haruslah ada sebuah basis data untuk menyimpan data transaksi dan data barang yang dijual. Kedua data ini akan diimplementasikan dalam dua buah tabel dalam basis data,
4-11 yaitu tabel transaksi untuk menyimpan data transaksi dan tabel barangTransaksi untuk menyimpan data barang yang dijual dalam suatu transaksi.
Skema basis data yang dibuat adalah sebagai berikut : Transaksi
= (id, waktu, jumlah)
BarangTransaksi
= (id, idTransaksi, idBarang, nama, jenis, harga)
Untuk implementasi dari basis data yang telah dirancang, dipilih database native Java yang dikembangkan oleh Apache yaitu Apache Derby. Pemilihan database Apache Derby karena Apache Derby adalah database yang dikembangkan dalam bahasa Java dan sudah didukung oleh SCA Runtime yang akan digunakan yaitu Apache Tuscany.
4.1.4.2
Identifikasi Service Operation
Setelah kegiatan refinement service dari kandidat service hasil analisis dilakukan, selanjutnya dilakukanlah kegiatan refinement terhadap kandidat service operation hasil analisis. Hasil dari kegiatan refinement ini diharapkan akan memunculkan service dan service operation yang mampu dijadikan masukan untuk dirubah menjadi assembly model SCA. Daftar service operation berikut service terkait dapat dilihat dalam Tabel 4-10.
Tabel 4-10. Daftar Service dan Service Operation No.
Service
Service Operation
1.
Transaksi
AddTransaction
ViewTransaction 2.
Member
CountPointMember AddPointMember
3.
Barang
UpdateDataBarang
4.
Manajemen Basis Data
GetDataTransaction AddDataTransaction
Service Operation Hasil Analisis Simpan Transaksi Input Transaksi Menyimpan Data Transaksi Lihat Transaksi Melihat data transaksi Hitung Poin Member Tambah Poin Member Input Poin Member Kirim Poin Member Menerima Input Poin Member Penambahan poin member Memasukkan nomor member pelanggan Kirim data barang terjual Melakukan update stok inventaris toko Akses data transaksi Akses data transaksi
Dari Tabel 4-10 dapat dilihat bahwa ada empat service berikut tujuh service operation yang merupakan hasil akhir dari proses refinement. Hasil berupa empat service dan tujuh service operation ini akan menjadi masukan untuk dirubah menjadi assembly model SCA.
4-12 4.1.5 Perancangan SCA Pada tahapan perancangan SCA ini service dan service operation yang telah didapatkan dalam tahapan analisis dan perancangan service di subbab 4.1.3. dan 4.1.4. akan menjadi input untuk pembuatan assembly model SCA. Setelah assembly model didapatkan akan dilakukan pemilihan client and implementation model untuk mengimplementasikan assembly model tersebut. Kemudian akan dilakukan pemilihan bindings untuk komunikasi antar komponen SCA dan setelah itu akan dilakukan pemilihan SCA Runtime untuk menjalankan aplikasi. Selanjutnya apabila aplikasi akan mempunyai sebuah basis data akan dilakukan perancangan basis data tersebut.
4.1.5.1
Pembuatan Assembly Model
Tahapan pembuatan assembly model dilakukan dengan mengubah service dan service operation yang telah ada menjadi elemen-elemen SCA yang telah dijelaskan dalam subbab 2.3.2. Pemetaan dari service menjadi elemen SCA dapat dilihat dalam Tabel 4-11 dan pemetaan dari service operation menjadi elemen SCA dapat dilihat dalam Tabel 4-12.
Tabel 4-11. Pemetaan Service menjadi Elemen SCA No. 1. 2. 3. 4.
Elemen Service Transaksi Barang Member Manajemen basis data
Elemen SCA TransactionServiceComponent InventoryServiceComponent MemberServiceComponent DataServiceComponenent
Tipe Elemen SCA SCA Component SCA Component SCA Component SCA Component
Tabel 4-12. Pemetaan Service Operation menjadi Elemen SCA No. 1. 2. 3. 4. 5. 6.
Elemen Service Operation Service operation service transaksi Service operation service member Service operation service inventaris Service operation service manajemen basis data Service operation service dari aplikasi pengelolaan data member Service operation service dari aplikasi pengelolaan inventaris toko
Elemen SCA TransactionService MemberService InventoryService
Tipe Elemen SCA SCA Service SCA Service SCA Service
DataService
SCA Service
MemberWSReference
SCA Reference
InventoryWSReference
SCA Reference
Service yang didapatkan sebelumnya dibentuk menjadi SCA Component, dan service operation yang menyertai service tersebut dibentuk menjadi SCA Service yang dipunyai oleh SCA Component yang bersangkutan. Selain itu service yang disediakan oleh aplikasi lain
4-13 yaitu dari aplikasi pengelolaan data member dan aplikasi pengelolaan inventaris toko akan digambarkan sebagai SCA Reference karena berkaitan dengan sistem lain di luar aplikasi.
Pemetaan keterhubungan antar elemen service seperti disebutkan di Tabel 4-11 dalam elemen SCA akan digambarkan dalam Tabel 4-13
Tabel 4-13. Pemetaan Keterhubungan Service menjadi Elemen SCA No. 1. 2. 3. 4. 5. 6.
Keterhubungan Service Service transaksi dengan client aplikasi Service transaksi dengan service member Service transaksi dengan service inventaris Service transaksi dengan service manajemen basis data Service inventaris dengan aplikasi pengelolaan inventaris toko
Elemen SCA transactionService memberService inventoryService
Tipe Elemen SCA SCA Promote SCA Reference SCA Reference
dataService
SCA Reference
inventoryWSReference
SCA Promote
Service member dengan pengelolaan data member
memberWSReference
SCA Promote
aplikasi
Gambar 4-4. Assembly Model SCA
4-14 Keterhubungan antar service dalam elemen SCA akan dibentuk dalam SCA Promote, dan SCA Reference. SCA Promote menggambarkan keterhubungan service yang dipunyai aplikasi dengan service lain di luar aplikasi, sedangkan SCA Reference menggambarkan keterhubungan antara service yang ada di dalam SCA Component dengan service lain yang dipunyai SCA Component lainnya dalam satu domain SCA yang sama.
Pemetaan service dan service operation menjadi elemen SCA serta keterhubungan antar service dan service operation akhirnya akan menghasilkan sebuah assembly model yang dapat dilihat dalam Gambar 4-4.
Keterangan legenda mengenai assembly model SCA dapat dilihat dalam gambar 2-17 dan 2-18 dalam subbab 2.3.2.1.
4.1.5.2
Pemilihan Client and Implementation Model
Saat ini SCA memiliki delapan Client and Implementation Model yang dapat dipilih seperti disebutkan dalam subbab 2.3.2.3. Client and Implementation Model yang dipilih untuk mengimplementasikan assembly model yang didapatkan dalam subbab 4.1.5.1. adalah Client and Implementation Model Java. Pemilihan ini didasarkan pada SCA Runtime untuk deployment aplikasi SCA nantinya. Saat ini SCA Runtime yang ada kebanyakan bersifat propeitary/license, dan untuk yang open source baru ada untuk mendukung bahasa Java yaitu Tuscany. Pembahasan lebih lanjut mengenai SCA Runtime ini akan dibahas lebih lanjut dalam subbab 4.1.5.4.
Selain karena SCA Runtime open source yang baru mendukung implementasi SCA dalam bahasa Java, pemilihan Client and Implementation Model Java juga didukung oleh adanya beberapa Client and Implementation Model dari SCA yang berbasis Java seperti Client and Implementation Model Spring (Framework Java), EJB (Java Beans), dan JAX-WS (Framework Java), sehingga dengan memilih Java maka dapat dengan mudah digabungkan dengan Client and Implementation Model lainnya jika diinginkan.
Spesifikasi dari Client and Implementation Model Java ini dapat dilihat pada [OPE407] dan [OPE607].
4.1.5.3
Pemilihan Bindings
Pemilihan bindings adalah untuk mendefinisikan cara berkomunikasi antar elemen SCA yang ada, yaitu dari SCA Component dengan SCA Component lainnya melalui SCA Service dan SCA Reference. Saat ini telah ada 4 spesifikasi bindings untuk SCA seperti disebutkan
4-15 dalam subbab 2.3.2.3. Pemetaan keterhubungan antar elemen SCA dengan bindings yang sesuai dapat dilihat dalam Tabel 4-14
Tabel 4-14. Pemetaan Keterhubungan Elemen SCA dengan Bindings No. 1. 2. 3. 4. 5. 6.
Keterhubungan antar elemen SCA transactionService memberService inventoryService dataService inventoryWSReference memberWSReference
Bindings Implisit dengan Java Implisit dengan Java Implisit dengan Java Implisit dengan Java Web Service Bindings Web Service Bindings
Bindings yang digunakan untuk keterhubungan antar elemen SCA dalam satu domain yang sama tidak dideklarasikan secara eksplisit, namun secara implisit. Hubungan antar elemen SCA dalam satu domain tersebut akan menggunakan implementasi yang sama dengan implementasi dari SCA Component yang ada, yaitu dengan menggunakan Java. Sementara itu hubungan antar elemen SCA dengan elemen di luar domain akan dideklarasikan secara eksplisit, sehingga untuk hubungan dengan aplikasi pengelolaan inventaris toko dan aplikasi pengelolaan member akan menggunakan Web Service Bindings.
Spesifikasi dari Web Service Bindings dapat dilihat pada [OPE507].
4.1.5.4
Pemilihan SCA Runtime
Pemilihan SCA Runtime didasarkan pada kemampuan SCA Runtime tesebut untuk memenuhi standar spesifikasi SCA dan ketersediaan dari SCA Runtime tersebut untuk digunakan. Oleh karena itu SCA Runtime yang dipilih haruslah memenuhi standar SCA dan bersifat open source sehingga SCA Runtime yang dipilih adalah SCA Runtime open source berbasis Java, yaitu Apache Tuscany. Saat ini Apache Tuscany adalah SCA Runtime open source yang paling stabil dan telah memenuhi standar spesifikasi SCA v.1.0. Karena Apache Tuscany berbasis Java dan baru mendukung untuk pembuatan aplikasi SCA dengan Java, maka pembuatan aplikasi SCA harus menggunakan Java agar mampu dijalankan oleh SCA Runtime ini.
4.1.6 Implementasi SCA Assembly model yang telah didapatkan dalam subbab 4.1.5.1. selanjutnya akan diimplementasikan dengan menggunakan Client and Implementation Model dan Bindings yang telah ditentukan dalam subbab 4.1.5.2. dan 4.1.5.3. Didapatkan paket-paket seperti digambarkan dalam Gambar 4-5.
4-16
Gambar 4-5. Diagram Paket Aplikasi Akan ada empat paket utama, yaitu SIPOS yang memuat aplikasi utama SCA, SIMEMBER untuk representasi services dari aplikasi pengelolaan data member, SIBARANG untuk representasi services dari aplikasi pengelolaan inventaris toko dan client untuk client pengguna aplikasi SCA. Paket SIPOS memiliki sub paket API untuk representasi interface dari service dan sub paket lib untuk implementasi service. Paket SIMEMBER dan SIBARANG memiliki sub paket interface untuk representasi interface dari service dalam bentuk JAX-RPC menggunakan Apache Axis2. Keterangan mengenai setiap paket dapat dilihat pada Tabel 4-15.
Tabel 4-15. Daftar Paket Aplikasi No. 1. 2.
Nama Paket SIPOS SIPOS.API
3.
SIPOS.lib
4. 5.
SIMEMBER SIMEMBER.interface
6. 7.
SIBARANG SIBARANG.interface
8.
Client
4.1.6.1
Keterangan Paket utama untuk aplikasi SCA transaksi penjualan Paket yang berisi interface service yang dimiliki oleh aplikasi transaksi penjualan Paket yang berisi implementasi service yang dimiliki oleh aplikasi transaksi penjualan Paket utama untuk representasi aplikasi pengelolaan data member Paket yang berisi interface web service yang dimiliki oleh aplikasi pengelolaan data member Paket utama untuk representasi aplikasi pengelolaan inventaris toko Paket yang berisi interface web service yang dimiliki oleh aplikasi inventaris toko Paket yang berisi client pengguna aplikasi transaksi penjualan
Kelas Implementasi SCA
Kelas implementasi SCA adalah kelas yang menjadi implementasi elemen-elemen SCA yang telah didefinisikan dalam assembly model dalam subbab 4.1.5.1. Akan ada 1 kelas untuk tiap elemen SCA, sehingga akan dihasilkan 15 kelas dalam 5 paket. Sub paket API dan interface akan memuat representasi dari SCA Service dan SCA Reference, sementara sub
4-17 paket lib akan memuat representasi dari SCA Component. Daftar kelas implementasi berikut elemen SCA padanannya dapat dilihat dalam Tabel 4-16.
Tabel 4-16. Daftar Kelas Implementasi SCA No. 1.
Nama Paket SIPOS.API
2.
SIPOS.lib
3. 4. 5.
SIMEMBER.int erface SIBARANG.inte rface Client
Nama Kelas TransactionService DataService InventoryService MemberService Transaction Barang TransactionService Impl DataServiceImpl InventoryServiceImpl MemberServiceImpl TransactionImpl BarangImpl SIBARANGPortType
Elemen SCA Padanan transactionService dataService inventoryService memberService representasi data transaksi representasi data barang TransactionService
Tipe Kelas Java Interface Interface Interface Interface Interface Interface Class
DataService InventoryService MemberService representasi data transaksi representasi data barang barangWSReference
Class Class Class Class Class Interface
SIMEMBERPortType
memberWSReference
Interface
Client
representasi client aplikasi
Class
Diagram kelas per paket dapat dilihat dalam Gambar 4-6, sedangkan gambaran diagram kelas keseluruhan dapat dilihat dalam Gambar 4-7.
Gambar 4-6. Diagram Kelas Per Paket
4-18
Gambar 4-7. Diagram Kelas Keseluruhan 4.1.6.2
Deployment Diagram
Implementasi dari aplikasi transaksi penjualan direncanakan akan di-deploy pada Apache Tuscany berikut client pengguna aplikasi transaksi penjualan tersebut. Apache Derby yang merepresentasikan basis data yang digunakan dalam aplikasi transaksi penjualan tidak dideploy dalam suatu server tersendiri melainkan akan bersifat embedded dalam aplikasi transaksi penjualan. Aplikasi transaksi penjualan akan berinteraksi dengan client dengan menggunakan services dan untuk berinteraksi dengan Apache Derby akan menggunakan JDBC (Java DataBase Connectivity).
Aplikasi pengelolaan inventaris toko dan aplikasi pengelolaan data member akan dideploy dalam sebuah apache web server dan basis data dari kedua aplikasi tersebut akan dideploy dalam sebuah mySQL Server. Aplikasi pengelolaan inventaris toko dan aplikasi pengelolaan data member akan berinteraksi dengan mySQL server dengan menggunakan SQLConnect yang dimiliki oleh PHP. Kedua aplikasi akan berinteraksi dengan aplikasi transaksi penjualan dengan menggunakan web services. Untuk lebih jelasnya dapat dilihat dalam gambar 4-8.
4-19
Gambar 4-8. Deployment Diagram
4.2 Aplikasi Pengelolaan Data Member (SIMEMBER) Aplikasi SIMEMBER adalah aplikasi pengelolaan data member yang akan terhubung dengan aplikasi transaksi penjualan dengan menggunakan web services. Detil lengkap mengenai aplikasi ini dapat dilihat dalam dokumen teknis bagian lampiran A.
4.2.1 Deskripsi Umum Sistem Aplikasi pengelolaan data member (SIMEMBER) adalah sebuah aplikasi berbasis web yang mempunyai fungsi untuk mengelola data-data pelanggan yang menjadi member pada sebuah toko. Melalui aplikasi ini, penggunannya dapat melakukan pengelolaan terhadap data member seperti menambah, melihat, mengedit, dan menghapus data member yang ada. Selain itu, aplikasi juga memberikan layanan yang dapat dipergunakan oleh aplikasi pengelolaan data transaksi melalui web services. Layanan yang diberikan adalah layanan pemuktahiran poin yang dimiliki oleh seorang member. Aplikasi pengelolaan data transaksi hanya perlu memberikan input berupa id member dan jumlah poin tambahan lalu SIMEMBER secara otomatis akan menambahkan poin tersebut dengan poin member yang ada di dalam basis data sekaligus melakukan pemuktahiran terhadap data poin.
4-20 Fitur yang dimiliki oleh aplikasi ini adalah : 1. Melakukan pengelolaan terhadap data member berupa menambah, melihat, mengubah, dan menghapus data member 2. Memberikan layanan berupa pemuktahiran poin member yang bisa digunakan oleh aplikasi lain dengan web services.
4.2.2 Use Case Model Pada bagian ini akan dilakukan pemodelan kebutuhan aplikasi dengan menggunakan use case model. Akan didefinisikan lima use case yang mencakup keseluruhan kebutuhan aplikasi dengan dua aktor yang akan melakukan interaksi dengan aplikasi. Pembuatan model use case akan mencakup diagram use case keseluruhan dalam gambar 4-9, pendefinisian aktor dalam tabel 4-1, pendefinisian use case dalam tabel 4-2, dan skenario use case dalam subbab 4.2.2.4.
4.2.2.1
Diagram Use Case
Gambar 4-9 menunjukkan gambaran use case dalam aplikasi pengelolaan data member (SIMEMBER). Akan ada seorang pengguna yang akan menggunakan aplikasi ini, dan pengguna tersebut dapat melakukan kegiatan yang berkaitan dengan pengelolaan data member seperti melakukan menambah data member, melihat data member yang ada, mengubah data member yang ada, serta melakukan penghapusan data member. Selain pengelolaan data member yang dilakukan oleh pengguna, aplikasi ini juga akan terhubung pada suatu aplikasi pengelolaan transaksi penjualan yang dapat melakukan pemutakhiran terhadap poin member dengan melakukan akses terhadap layanan web services yang disediakan oleh aplikasi.
Gambar 4-9. Diagram Use Case SIMEMBER
4-21 4.2.2.2
Definisi Aktor
Tabel 4-17 memuat daftar sebagian aktor yang terlibat dalam aplikasi ini. Untuk lebih lengkapnya, dapat dilihat dalam dokumen teknis lampiran A subbab A.1.2.2.
Tabel 4-17. Daftar Aktor No. 1.
Id AKT-SIMEMBER-001
4.2.2.3
Nama Pengguna
Deskripsi Orang yang menggunakan aplikasi untuk melakukan pengelolaan data member seperti menambah, melihat, mengubah, dan menghapus data member
Definisi Use Case
Tabel 4-18 memuat definisi dari sebagian use case yang terdapat dalam aplikasi ini. Untuk lebih lengkapnya dapat dilihat dalam dokumen teknis lampiran A subbab A.1.2.3.
Tabel 4-18. Daftar Use Case No. 1.
Id UC- SIMEMBER-001
Nama Menambah data member
Deskripsi Melakukan penambahan data member untuk dimasukkan ke dalam basis data
2.
UC- SIMEMBER-005
Memuktahirkan poin member
Menerima input id member dan poin member dari aplikasi pengelolaan transaksi penjualan lalu melakukan pemuktahiran terhadap poin member yang ada dalam basis data
4.2.2.4
Skenario Use Case
Skenario dari keseluruhan use case dapat dilihat dalam dokumen teknis lampiran A subbab A.1.2.4. ID Nama Use Case Aktor Prekondisi Frekuensi Skenario
: UC-SIMEMBER-01 : Menambah data member : Pengguna :: Sering :
Aksi Aktor Skenario Normal (SN-UC-SIMEMBER-01) 1. Memilih pilihan tambah data member
Reaksi Sistem
2. Menampilkan form pengisian data member 3. Mengisi form pengisian data member 4. Menyimpan form pengisian data member 5. Menyimpan data member baru dalam basis data
ID Nama Use Case Aktor
: UC-SIMEMBER-05 : Memutakhirkan data member : Aplikasi pengelolaan transaksi penjualan
4-22 Prekondisi Frekuensi Skenario
:: Sering :
Aksi Aktor Skenario Normal (SN-UC-SIMEMBER-01) 1. Mengirim id dan poin member
Reaksi Sistem
2. Menghitung poin total dengan menambahkan poin lama dan poin baru 3. Menyimpan data poin baru dalam basis data
4.3 Aplikasi Pengelolaan Inventaris Toko (SIBARANG) Aplikasi SIBARANG adalah aplikasi pengelolaan data barang yang akan terhubung dengan aplikasi transaksi penjualan dengan menggunakan web services. Detil lengkap mengenai aplikasi ini dapat dilihat dalam dokumen teknis bagian lampiran B.
4.3.1 Deskripsi Umum Sistem Aplikasi pengelolaan data barang “SIBARANG” adalah sebuah aplikasi berbasis web yang mempunyai fungsi untuk mengelola data-data barang pada sebuah toko. Melalui aplikasi ini, penggunanya dapat melakukan pengelolaan terhadap data barang seperti menambah, melihat, mengedit, dan menghapus data barang yang ada. Selain itu, aplikasi lain juga memberikan layanan yang dapat dipergunakan oleh aplikasi pengelolaan data transaksi melalui web services. Layanan yang diberikan adalah layanan pemuktahiran stok yang dimiliki oleh barang. Aplikasi pengelolaan data transaksi hanya perlu memberikan input berupa id barang dan stok barang yang terjual lalu SIBARANG secara otomatis akan memuktahirkan stok barang yang ada ada di dalam basis data.
Fitur yang dimiliki oleh aplikasi ini adalah : 1. Melakukan pengelolaan terhadap data barang berupa menambah, melihat, mengubah, dan menghapus data barang 2. Memberikan layanan berupa pemuktahiran stok barang yang bisa digunakan oleh aplikasi lain dengan web services.
4.3.2 Model Use Case Pada bagian ini akan dilakukan pemodelan kebutuhan aplikasi dengan menggunakan use case model. Akan didefinisikan lima use case yang mencakup keseluruhan kebutuhan aplikasi dengan dua aktor yang akan melakukan interaksi dengan aplikasi. Pembuatan model use case akan mencakup diagram use case keseluruhan dalam Gambar 4-10, pendefinisian aktor dalam Tabel 4-19, pendefinisian use case dalam Tabel 4-20, dan skenario use case dalam subbab 4.3.2.4.
4-23 4.3.2.1
Diagram Use Case
Gambar 4-10. Diagram Use Case SIBARANG Gambar 4-10 menunjukkan gambaran mengenai use case yang dibuat dalam aplikasi pengelolaan inventaris toko (SIBARANG). Akan ada seorang pengguna yang akan menggunakan aplikasi ini, dan pengguna tersebut dapat melakukan kegiatan yang berkaitan dengan pengelolaan data barang seperti melakukan menambah data barang, melihat data barang yang ada, mengubah data barang yang ada, serta melakukan penghapusan data barang. Selain pengelolaan data barang yang dilakukan oleh pengguna, aplikasi ini juga akan terhubung pada suatu aplikasi pengelolaan transaksi penjualan yang dapat melakukan pemutakhiran terhadap stok barang dengan melakukan akses terhadap layanan web services yang disediakan oleh aplikasi.
4.3.2.2
Definisi Aktor
Tabel 4-19 memuat daftar sebagian aktor yang terlibat dalam aplikasi ini. Untuk lebih lengkapnya, dapat dilihat dalam dokumen teknis lampiran B subbab B.1.2.2.
Tabel 4-19. Daftar Aktor No. 1.
Id AKTSIBARANG001
4.3.2.3
Nama Pengguna
Deskripsi Orang yang menggunakan aplikasi untuk melakukan pengelolaan data barang seperti menambah, melihat, mengubah, dan menghapus data barang
Definisi Use Case
Tabel 4-20 memuat definisi dari sebagian use case yang terdapat dalam aplikasi ini. Untuk lebih lengkapnya dapat dilihat dalam dokumen teknis lampiran B subbab B.1.2.3.
4-24 Tabel 4-20. Daftar Use Case No. 1.
2.
Id UCSIBARANG001 UCSIBARANG005
4.3.2.4
Nama Menambah data barang
Deskripsi Melakukan penambahan data barang untuk dimasukkan ke dalam basis data
Memuktahirkan stok barang
Menerima input id barang dan stok barang dari aplikasi pengelolaan transaksi penjualan lalu melakukan pemuktahiran terhadap stok barang yang ada dalam basis data
Skenario Use Case
Skenario dari keseluruhan use case dapat dilihat dalam dokumen teknis lampiran B subbab B.1.2.4. ID Nama Use Case Aktor Prekondisi Frekuensi Skenario
: UC- SIBARANG-01 : Menambah data barang : Pengguna :: Sering :
Aksi Aktor Skenario Normal (SN-UC- SIBARANG-01) 1. Memilih pilihan tambah data barang
Reaksi Sistem
2. Menampilkan form pengisian data barang 3. Mengisi form data barang 4. Menyimpan form data barang 5. Menyimpan data barang baru dalam basis data
ID Nama Use Case Aktor Prekondisi Frekuensi Skenario
: UC-SIBARANG-05 : Memutakhirkan data barang : Aplikasi pengelolaan transaksi penjualan :: Sering :
Aksi Aktor Skenario Normal (SN-UC--SIBARANG-01) 1. Mengirim id dan stok barang
Reaksi Sistem
2. Menghitung stok total dengan mengurangi stok lama dan stok terjual 3. Menyimpan data stok baru dalam basis data
