BAB 4 ANALISIS DAN PERANCANGAN APLIKASI

(1)

4-1

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.

(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.

(3)

Tabel 4-1. Daftar Kebutuhan Fungsional Aplikasi Transaksi Penjualan

No. SRS ID Keterangan

1. SRS-SIPOS-01 Penerimaan input nomor member dari kasir

2. SRS-SIPOS-02 Pengelolaan data barang yang dijual 3. SRS-SIPOS-03 Perhitungan poin hasil transaksi penjualan

4. SRS-SIPOS-04 Melakukan penambahan terhadap poin member ke aplikasi pengelolaan data member

5. SRS-SIPOS-05 Melakukan pengurangan stok barang ke aplikasi pengelolaan inventaris took

4.1.2.2 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.

(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. ID Use Case Nama Deskripsi 1. UC-SIPOS-01 Mengelola transaksi

penjualan

Use case dimana transaksi penjualan yang terjadi

mampu untuk ditambah dan dilihat

Tabel 4-3. Tabel Aktor Aplikasi

No. ID Aktor Nama Deskripsi 1. AKT-

SIPOS-01

Kasir 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

(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 :

(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. Langkah dalam Business Process Kandidat Service 1. Pelanggan menaruh barang belanjaan di kasir -

2. Kasir memasukkan data barang yang dijual Service memasukkan data transaksi

3. Kasir meminta nomor member pelanggan Service memasukkan nomor member pelanggan

4. Tambahkan nilai poin ke data member pada aplikasi pengelolaan data member

Service penambahan poin member

5. Update stok inventaris barang pada aplikasi

pengelolaan inventaris toko

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. Use Case Kandidat Service

1. Mengelola transaksi penjualan Service melihat data transaksi Service memasukkan data transaksi

2. Mengupdate stok inventaris barang Service melakukan update stok inventaris toko

3. Menambah poin member 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.

(7)

Tabel 4-6. Kandidat Service Task-Oriented Business Process Final

No. Kandidat Service Task - Oriented Business Service dari Business Process

Kandidat Service Task-Oriented Business Service dari Use Case

Kandidat Service Task-Oriented Business Service Akhir

1. Service memasukkan data

transaksi

Service memasukkan data

transaksi

Service memasukkan data

transaksi

2. - Service melihat data transaksi Service melihat data

transaksi 3. Service memasukkan nomor

member pelanggan

- Service memasukkan nomor member pelanggan

4. Service penambahan poin

member

Service penambahan poin member

5. Service melakukan update

stok inventaris stok

Service melakukan update stok

inventaris toko

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 service-service 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.

(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 operasi-operasi / 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 Jenis Service Service Service Operation Deskripsi S-SIPOS-01 Process Service Melakukan transaksi Input transaksi Melakukan

transaksi penjualan yang terjadi pada suatu waktu S-SIPOS-02 Entity-Centric

Business Service

Transaksi Simpan transaksi Menyimpan transaksi ke dalam basis data

Lihat transaksi Melihat transaksi yang telah ada dalam basis data S-SIPOS-03 Entity-Centric

Business Service

Member Kirim nomor

member Mengirim nomor member Hitung poin member Menghitung poin member yang didapatkan dalam suatu transaksi S-SIPOS-04 Entity-Centric Business Service

Barang Hitung barang

terjual Menghitung jumlah barang terjual S-SIPOS-05 Task-Centric Business Service Memasukkan data transaksi Menyimpan Data Transaksi Menyimpan transaksi penjualan yang terjadi pada suatu waktu

(9)

Tabel 4-7. Daftar Kandidat Service dan Service Operation (Lanjutan)

Service ID Jenis Service Service Service Operation Deskripsi S-SIPOS-06 Task-Centric Business Service Melihat data transaksi Melihat data transaksi Melihat transaksi yang telah ada dalam basis data S-SIPOS-07 Task-Centric Business Service Memasukkan nomor member pelanggan Memasukkan nomor member pelanggan Menerima input nomor member S-SIPOS-08 Task-Centric Business Service Penambahan poin member Penambahan poin member Menambah poin member dengan poin transaksi S-SIPOS-09 Task-Centric Business Service Melakukan update stok inventaris toko

Melakukan update stok inventaris toko Melakukan update terhadap stok inventaris toko S-SIPOS-10 Application Service Manajemen Basis Data Akses data transaksi 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 Use Case ID Service ID

SRS-SIPOS-01 UC-SIPOS-03 S-SIPOS-03, S-SIPOS-07

SRS-SIPOS-02 UC-SIPOS-01 S-SIPOS-01, S-SIPOS-02, S-SIPOS-10, S-SIPOS-05, S-SIPOS-06

SRS-SIPOS-03 UC-SIPOS-03 S-SIPOS-03

SRS-SIPOS-04 UC-SIPOS-03 S-SIPOS-03, S-SIPOS-08 SRS-SIPOS-05 UC-SIPOS-02 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 2-11, 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.

(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 task-oriented business service dengan kandidat entity-task-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. Service Hasil Analisis Service Hasil Desain 1. Melakukan transaksi Transaksi 2. Transaksi

3. Memasukkan data transaksi 4. Melihat data transaksi

5. Member Member

6. Memasukkan nomor

member pelanggan

7. Penambahan poin member

8. Barang Barang

9. Melakukan update stok

inventaris toko

10. Manajemen Basis Data 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,

(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 Service Operation Hasil Analisis

1. Transaksi AddTransaction Simpan Transaksi

Input Transaksi

Menyimpan Data Transaksi

ViewTransaction Lihat Transaksi Melihat data transaksi 2. Member CountPointMember Hitung Poin Member

AddPointMember Tambah Poin Member Input Poin Member Kirim Poin

Member

Menerima Input Poin Member Penambahan poin member Memasukkan nomor member pelanggan

3. Barang UpdateDataBarang Kirim data barang terjual Melakukan update stok inventaris toko

4. Manajemen Basis Data GetDataTransaction Akses data transaksi

AddDataTransaction 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.

(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. Elemen Service Elemen SCA Tipe Elemen SCA

1. Transaksi TransactionServiceComponent SCA Component

2. Barang InventoryServiceComponent SCA Component

3. Member MemberServiceComponent SCA Component

4. Manajemen basis data DataServiceComponenent SCA Component

Tabel 4-12. Pemetaan Service Operation menjadi Elemen SCA

No. Elemen Service Operation Elemen SCA Tipe Elemen SCA 1. Service operation service transaksi TransactionService SCA Service

2. Service operation service member MemberService SCA Service

3. Service operation service

inventaris

InventoryService SCA Service

4. Service operation service

manajemen basis data

DataService SCA Service

5. Service operation service dari

aplikasi pengelolaan data member

MemberWSReference SCA Reference

6. Service operation service dari

aplikasi pengelolaan inventaris toko

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

(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. Keterhubungan Service Elemen SCA Tipe Elemen SCA 1. Service transaksi dengan client aplikasi transactionService SCA Promote

2. Service transaksi dengan service member memberService SCA Reference

3. Service transaksi dengan service

inventaris

inventoryService SCA Reference

4. Service transaksi dengan service

manajemen basis data

dataService SCA Reference

5. Service inventaris dengan aplikasi

pengelolaan inventaris toko

inventoryWSReference SCA Promote

6. Service member dengan aplikasi

pengelolaan data member

memberWSReference SCA Promote

(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

(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. Keterhubungan antar elemen SCA Bindings

1. transactionService Implisit dengan Java 2. memberService Implisit dengan Java 3. inventoryService Implisit dengan Java 4. dataService Implisit dengan Java

5. inventoryWSReference Web Service Bindings

6. memberWSReference 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.

(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. Nama Paket Keterangan

1. SIPOS Paket utama untuk aplikasi SCA transaksi penjualan

2. SIPOS.API Paket yang berisi interface service yang dimiliki oleh aplikasi transaksi penjualan

3. SIPOS.lib Paket yang berisi implementasi service yang dimiliki oleh aplikasi transaksi penjualan

4. SIMEMBER Paket utama untuk representasi aplikasi pengelolaan data member 5. SIMEMBER.interface Paket yang berisi interface web service yang dimiliki oleh aplikasi

pengelolaan data member

6. SIBARANG Paket utama untuk representasi aplikasi pengelolaan inventaris toko 7. SIBARANG.interface Paket yang berisi interface web service yang dimiliki oleh aplikasi

inventaris toko

8. Client Paket yang berisi client pengguna aplikasi transaksi penjualan

4.1.6.1 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

(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. Nama Paket Nama Kelas Elemen SCA Padanan Tipe Kelas Java 1. SIPOS.API TransactionService transactionService Interface

DataService dataService Interface InventoryService inventoryService Interface MemberService memberService Interface Transaction representasi data transaksi Interface

Barang representasi data barang Interface

2. SIPOS.lib TransactionService Impl

TransactionService Class

DataServiceImpl DataService Class InventoryServiceImpl InventoryService Class MemberServiceImpl MemberService Class TransactionImpl representasi data transaksi Class BarangImpl representasi data barang Class

3. SIMEMBER.int erface

SIBARANGPortType barangWSReference Interface

4. SIBARANG.inte rface

SIMEMBERPortType memberWSReference Interface

5. Client 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.

(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 di-deploy 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 deploy dalam sebuah apache web server dan basis data dari kedua aplikasi tersebut akan di-deploy 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.

(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.

(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.

(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. Id Nama Deskripsi

1. AKT-SIMEMBER-001 Pengguna Orang yang menggunakan aplikasi untuk melakukan pengelolaan data member seperti menambah, melihat, mengubah, dan menghapus data member

4.2.2.3 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

1. UC- SIMEMBER-001 Menambah data member 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 : UC-SIMEMBER-01

Nama Use Case : Menambah data member

Aktor : Pengguna

Prekondisi : -

Frekuensi : Sering

Skenario :

Aksi Aktor Reaksi Sistem

Skenario Normal (SN-UC-SIMEMBER-01) 1. Memilih pilihan tambah data member

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 : UC-SIMEMBER-05

Nama Use Case : Memutakhirkan data member

(22)

Prekondisi : -

Frekuensi : Sering

Skenario :

Skenario Normal (SN-UC-SIMEMBER-01) 1. Mengirim id dan poin member

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.

(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

1. AKT- SIBARANG-001

Pengguna Orang yang menggunakan aplikasi untuk melakukan pengelolaan data barang seperti menambah, melihat, mengubah, dan menghapus data barang

4.3.2.3 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.

(24)

Tabel 4-20. Daftar Use Case

1. UC- SIBARANG-001

Menambah data barang Melakukan penambahan data barang untuk dimasukkan ke dalam basis data

2. UC- SIBARANG-005

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