BAB 4 ANALISIS DAN PERANCANGAN APLIKASI

Transkripsi

1 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 dan untuk pembangunan aplikasi SIPOS dilakukan dengan mengkuti metodologi yang telah dibahas dalam subbab 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

2 4-2 Gambar 4-1. Business Process Penjualan Barang Pemodelan Kebutuhan Aplikasi 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 4-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 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 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-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 Use case dimana transaksi penjualan yang terjadi penjualan mampu untuk ditambah dan dilihat Tabel 4-3. Tabel Aktor Aplikasi No. ID Aktor Nama Deskripsi 1. AKT- SIPOS- Kasir Aktor pengguna aplikasi transaksi penjualan, 01 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

5 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 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 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 dan identifikasi sistem yang telah ada dimasukkan dalam model use case dalam subbab 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 serta business process dalam subbab 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 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 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 Service penambahan poin member aplikasi pengelolaan data 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 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 4-7 Tabel 4-6. Kandidat Service Task-Oriented Business Process Final No. Kandidat Service Task - Oriented Business Service dari Business Process 1. Service memasukkan data transaksi Kandidat Service Task- Oriented Business Service dari Use Case Service memasukkan data transaksi Kandidat Service Task- Oriented Business Service Akhir 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 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 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.

8 4-8 Gambar 4-3. Hasil Identifikasi Kandidat Service Identifikasi Kandidat Service Operation Identifikasi kandidat service operation dilakukan dengan melihat kandidat service yang telah diidentifikasi sebelumnya pada subbab 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 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 S-SIPOS-03 S-SIPOS-04 Entity-Centric Business Service Entity-Centric Business Service Entity-Centric Business Service Transaksi Simpan transaksi Menyimpan transaksi ke dalam basis data Member Barang Lihat transaksi Kirim nomor member Hitung poin member Hitung barang terjual Melihat transaksi yang telah ada dalam basis data Mengirim nomor member Menghitung poin member yang didapatkan dalam suatu transaksi 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 4-9 Tabel 4-7. Daftar Kandidat Service dan Service Operation (Lanjutan) Service ID Jenis Service Service Service Operation Deskripsi S-SIPOS-06 Task-Centric Melihat data Melihat data Melihat transaksi Business Service transaksi transaksi yang telah ada S-SIPOS-07 S-SIPOS-08 S-SIPOS-09 S-SIPOS-10 Task-Centric Business Service Task-Centric Business Service Task-Centric Business Service Application Service Memasukkan nomor member pelanggan Penambahan poin member Melakukan update stok inventaris toko Manajemen Basis Data Memasukkan nomor member pelanggan Penambahan poin member Melakukan update stok inventaris toko Akses data transaksi 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 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 Perancangan Service Tahap berikutnya adalah perancangan service. Kegiatan yang dilakukan dalam tahapan ini berupa desain service dalam SOAD seperti disebutkan dalam subbab pada gambar 2-11, akan tetapi yang dilakukan dalam tahap ini adalah kegiatan refinement kandidat service dan service operation hasil analisis dalam subbab 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 telah cukup menggambarkan logika yang ada dalam orchestration layer SOA.

10 Identifikasi Service Dari hasil identifikasi kandidat service dalam subbab , 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. 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 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 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 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 Tabel 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 Perancangan SCA Pada tahapan perancangan SCA ini service dan service operation yang telah didapatkan dalam tahapan analisis dan perancangan service di subbab dan 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 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 Pemetaan dari service menjadi elemen SCA dapat dilihat dalam Tabel 4-11 dan pemetaan dari service operation menjadi elemen SCA dapat dilihat dalam Tabel Tabel 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 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 InventoryService SCA Service inventaris 4. Service operation service DataService SCA Service manajemen basis data 5. Service operation service dari MemberWSReference SCA Reference aplikasi pengelolaan data member 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 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 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 inventoryservice SCA Reference inventaris 4. Service transaksi dengan service dataservice SCA Reference manajemen basis data 5. Service inventaris dengan aplikasi pengelolaan inventaris toko inventorywsreference SCA Promote 6. Service member dengan aplikasi pengelolaan data member memberwsreference SCA Promote Gambar 4-4. Assembly Model SCA

14 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 Pemilihan Client and Implementation Model Saat ini SCA memiliki delapan Client and Implementation Model yang dapat dipilih seperti disebutkan dalam subbab Client and Implementation Model yang dipilih untuk mengimplementasikan assembly model yang didapatkan dalam subbab 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 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] 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 4-15 dalam subbab Pemetaan keterhubungan antar elemen SCA dengan bindings yang sesuai dapat dilihat dalam Tabel 4-14 Tabel 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] 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 Implementasi SCA Assembly model yang telah didapatkan dalam subbab selanjutnya akan diimplementasikan dengan menggunakan Client and Implementation Model dan Bindings yang telah ditentukan dalam subbab dan Didapatkan paket-paket seperti digambarkan dalam Gambar 4-5.

16 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 Tabel 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 Kelas Implementasi SCA Kelas implementasi SCA adalah kelas yang menjadi implementasi elemen-elemen SCA yang telah didefinisikan dalam assembly model dalam subbab 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 4-17 paket lib akan memuat representasi dari SCA Component. Daftar kelas implementasi berikut elemen SCA padanannya dapat dilihat dalam Tabel Tabel 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 TransactionService Class Impl DataServiceImpl DataService Class InventoryServiceImpl InventoryService Class MemberServiceImpl MemberService Class TransactionImpl representasi data transaksi Class BarangImpl representasi data barang Class 3. SIMEMBER.int SIBARANGPortType barangwsreference Interface erface 4. SIBARANG.inte SIMEMBERPortType memberwsreference Interface rface 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. Gambar 4-6. Diagram Kelas Per Paket

18 4-18 Gambar 4-7. Diagram Kelas Keseluruhan 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.

19 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 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 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 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 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

21 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 Tabel 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 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 Tabel Daftar Use Case No. Id Nama Deskripsi 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 Skenario Use Case Skenario dari keseluruhan use case dapat dilihat dalam dokumen teknis lampiran A subbab A ID : UC-SIMEMBER-01 Nama Use Case : Menambah data member Aktor : Pengguna Prekondisi : - Frekuensi : Sering Skenario : Aksi Aktor Skenario Normal (SN-UC-SIMEMBER-01) 1. Memilih pilihan tambah data member 3. Mengisi form pengisian data member 4. Menyimpan form pengisian data member Reaksi Sistem 2. Menampilkan 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

22 4-22 Prekondisi : - Frekuensi : Sering Skenario : 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 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 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

23 Diagram Use Case Gambar 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 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 Tabel Daftar Aktor No. Id Nama Deskripsi 1. AKT- SIBARANG- 001 Pengguna 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

24 4-24 Tabel Daftar Use Case No. Id Nama Deskripsi 1. UC- SIBARANG- 001 Menambah data barang 2. UC- SIBARANG- 005 Memuktahirkan stok barang Skenario Use Case Melakukan penambahan data barang untuk dimasukkan ke dalam basis data Menerima input id barang dan stok barang dari aplikasi pengelolaan transaksi penjualan lalu melakukan pemuktahiran terhadap stok barang yang ada dalam basis data Skenario dari keseluruhan use case dapat dilihat dalam dokumen teknis lampiran B subbab B ID : UC- SIBARANG-01 Nama Use Case : Menambah data barang Aktor : Pengguna Prekondisi : - Frekuensi : Sering Skenario : Aksi Aktor Skenario Normal (SN-UC- SIBARANG-01) 1. Memilih pilihan tambah data barang 3. Mengisi form data barang 4. Menyimpan form data barang Reaksi Sistem 2. Menampilkan form pengisian data barang 5. Menyimpan data barang baru dalam basis data ID : UC-SIBARANG-05 Nama Use Case : Memutakhirkan data barang Aktor : Aplikasi pengelolaan transaksi penjualan Prekondisi : - Frekuensi : Sering Skenario : 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