Bab ini berisi tentang kesimpulan dan saran dari penulisan laporan tugas akhir yang disusun.
BAB II
LANDASAN TEORI
2.1Manajemen Transaksi
Transaksi merupakan kegiatan atau sekumpulan kegiatan yang dilakukan oleh seorang pengguna atau program aplikasi yang membaca atau mengubah konten pada basis data. Transaksi mempunyai sifat yang disebut ACID, yaitu (Haerder dan Reuter, 1983):
a. Atomicity, di mana sebuah transaksi merupakan sebuah unit yang tidak dapat dibagi yang dilakukan secara keseluruhan atau tidak sama sekali. b. Consistency, di mana sebuah transaksi dapat mengubah basis data dari
suatu keadaan konsisten ke keadaan konsisten lainnya.
c. Isolation, di mana transaksi dijalankan secara bebas. Dengan kata lain, jika terjadi transaksi yang tidak selesai, maka transaksi lain tidak akan terpengaruh.
d. Durability, di mana transaksi dapat tercatat secara permanen dalam basis data dan tidak hilang karena kesalahan pada transaksi berikutnya.
Untuk menciptakan transaksi yang menciptakan hasil yang sesuai dan dapat meningkatkan integritas dan konsistensi basis data, maka dibutuhkan concurrency control. Concurrency control merupakan proses mengatur kegiatan yang terjadi secara bersamaan pada basis data tanpa harus
mengganggu transaksi satu sama lain. Masalah yang dapat terjadi jika tidak ada kontrol terhadap concurrency :
a. The lost update problem
Merupakan masalah yang terjadi jika data transaksi yang telah di-update tidak diakses oleh transaksi yang lainnya. Misalnya transaksi A melakukan perubahan pada data A. Kemudian transaksi B mengakses data A sebelum diubah transaksi A dan kemudian melakukan perubahan terhadap data A tersebut. Maka yang tercatat hanya perubahan data yang dilakukan oleh transaksi B.
b. The uncommitted dependency (dirty read) problem
Masalah ini terjadi jika suatu transaksi melakukan perubahan data. Kemudian data tersebut digunakan oleh transaksi lainnya, meskipun transaksi yang melakukan perubahan data tersebut membatalkan perubahan data yang dilakukan. Misalnya transaksi A mengubah data A dan data tersebut digunakan transaksi B untuk melakukan perubahan terhadap data A. Kemudian transaksi A membatalkan seluruh kegiatan transaksinya, maka data A menjadi tidak akurat.
c. The inconsistent analysis problem
Masalah ini disebabkan oleh dua transaksi yang mengakses sumber yang sama pada waktu yang bersamaan. Transaksi yang pertama melakukan perubahan terhadap data, kemudian transaksi lainnya menggunakan data yang belum diubah untuk menganalisa data lainnya. Misalnya transaksi A mengubah data A. Transaksi B melakukan
perubahan pada data B berdasarkan data A yang belum mengalami perubahan yang dilakukan oleh transaksi A. Ini menyebabkan data B menjadi data yang tidak konsisten.
2.1.1 Locking Methods (Metode-metode penguncian)
Locking adalah suatu prosedur yang digunakan untuk mengendalikan akses bersamaan pada suatu data. Saat sebuah transaksi mengakses basisdata, suatu kunci (lock) boleh menolak akses dari transaksi lain untuk mencegah hasil yang tidak benar. Sifat dasar locking pada sebuah transaksi adalah transaksi harus dinyatakan sebagai shared untuk proses baca (read) dan sepenuhnya terkunci untuk proses tulis (write). Aturan pada locking adalah :
1. Shared lock yaitu jika suatu transaksi memiliki suatu shared lock pada item datanya, maka data tersebut dapat dibaca namun tidak dapat diubah.
2. Exclusive lock yaitu jika suatu transaksi memiliki suatu exclusive lock pada item datanya, maka data tersebut dapat dibaca dan dapat diubah.
Karena operasi baca tidak menimbulkan konflik, maka diijinkan lebih dari 1 transaksi untuk melakukan lock bersama secara serentak pada saat yang bersamaan. Sedangkan pada exclusive lock jika suatu transaksi melakukan exclusive lock pada suatu item data, maka tidak
ada transaksi-transaksi lain dapat membaca atau mengubah item data tersebut. Locks dapat dilakukan dengan cara sebagai berikut :
1. Setiap transaksi perlu mengakses suatu item data maka pertama-tama ia harus meminta shared lock untuk akses baca saja atau exclusive lock untuk akses baca dan tulis.
2. Jika item data tersebut belum dikunci oleh transaksi lain, maka lock akan diberikan.
3. Jika item data tersebut sedang dikunci, DBMS akan menentukan apakah permintaan tersebut cocok atau sesuai dengan kondisi lock yang sedang aktif. Jika shared lock diminta pada saat suatu item data tersebut sedang dalam kondisi shared lock, maka permintaan shared lock akan diberikan. Sebaliknya jika tidak, transaksi tersebut harus menunggu (waiting) sampai lock yang sedang aktif dilepaskan atau dibuka.
4. Sebuah transaksi melakukan lock sampai dilepaskan pada saat eksekusi atau saat operasi transaksi berakhir (abort atau commit). Efek dari perubahan data dapat dilihat oleh transaksi lain hanya pada saat exclusive lock telah dilepaskan.
Sebagai tambahan dari peraturan tersebut, beberapa sistem mengijinkan untuk :
1. Upgrade the lock (meningkatkan penguncian) yaitu dari shared lock ke exclusive lock.
2. Downgrade the lock (menurunkan penguncian) yaitu dari exclusive lock ke shared lock.
2.1.2 Two Phase Locking (2PL)
Sebuah Transaksi menerapkan protokol 2PL jika semua operasi locking mendahului operasi yang tak terkunci (unlock) dalam transaksi tersebut. Menurut aturan tersebut, setiap transaksi dapat dibagi mejadi 2 fase, yaitu :
1. Growing phase : memperoleh semua locks yang dibutuhkan tetapi tidak dapat melepaskan satu locks pun.
2. Shrinking phase : melepaskan semua locks yang dimiliki tetapi tidak dapat memperoleh locks yang baru.
Peraturan yang ditetapkan adalah sebagai berikut :
1. Sebuah transaksi harus memperoleh suatu lock pada suatu item data, sebelum melakukan operasi terhadap data tersebut. Macam lock dapat untuk read atau write tergantung kebutuhan.
2. Sekali transaksi tersebut melepaskan suatu lock, maka transaksi tersebut tidak pernah bisa mendapatkan sejumlah lock baru yang lain.
2.2Use Case Diagram
Diagram use case adalah sebuah diagram yang menggambarkan interaksi antara sistem, eksternal sistem dan user. Secara grafis menggambarkan siapa yang akan menggunakan sistem dan dengan cara bagaimana user berinteraksi dengan sistem. Use case sendiri merupakan bagian dari keseluruhan sistem yang digambarkan dalam bentuk elips horisontal. Nama use case sendiri tertera di atas, di bawah atau di dalam elips. Gambar 2.1 di bawah ini merupakan simbol use case :
Gambar 2.1 Simbol Use Case
Aktor merupakan segala sesuatu yg perlu berinteraksi dengan sistem untuk mendapat/ mengubah informasi. Aktor dapat berupa orang, organisasi, sistem informasi yang lain, piranti luar (external device) atau waktu kejadian. Gambar 2.2 di bawah ini merupakan simbol aktor :
2.3Activity Diagram
Merupakan diagram yang digunakan untuk menggambarkan aliran sebuah proses bisnis, sebuah langkah dalam use case atau logika dari sifat objek. Notasi-notasi yang digunakan pada diagram ini antara lain:
1. Initial node : berbentuk lingkaran berwarna hitam yang menggambarkan dimulainya suatu proses.
2. Actions : berbentuk segi empat yang sisinya melengkung. Notasi ini menggambarkan langkah-langkah yang dilakukan secara berurutan untuk membentuk kegiatan secara keseluruhan.
3. Flow : disimbolkan dengan anak panah yang mengindikasikan pergerakan pada setiap kegiatan. Umumnya flow tidak diberi keterangan kecuali digambarkan keluar dari decisions.
4. Decision : disimbolkan dengan diamond dengan satu flow yang masuk dan dua atau lebih flow yang keluar. Flow yang keluar ditandai dengan suatu kondisi.
5. Merge : disimbolkan dengan diamond dengan dua atau lebih flow yang masuk dan satu flow yang keluar.
6. Fork : disimbolkan dengan bar hitam yang memiliki satu flow yang masuk dan dua atau lebih flow yang keluar.
7. Join : disimbolkan dengan bar hitam yang memiliki dua atau lebih flow yang masuk dan satu flow yang keluar. Semua actions yang masuk ke join harus diselesaikan terlebih dahulu sebelum proses berlanjut.
8. Activity final : digambarkan dengan lingkaran hitam yang berada di dalam lingkaran putih. Simbol ini menandakan akhir dari sebuah proses.
9. Subactivity indicator : simbol dalam aksi ini menandakan bahwa aksi dipecah menjadi diagram aktivitas yang terpisah. Hal ini untuk membantu agar diagram aktivitas tidak menjadi kompleks.
10.Connector : merupakan huruf di dalam lingkaran yang membantu untuk mengatur kompleksitas. Alur masuk ke dalam konektor akan melompat ke alur keluar dengan huruf yang sesuai.
Gambar 2.3, 2.4 dan 2.5 berikut merupakan gambar dari notasi-notasi yang telah dijelaskan sebelumnya.
2.4Class Diagram
2.4.1 Class Diagram Analisis
Class diagram analisis merupakan gambaran grafis dari struktur obyek statis sistem. Class diagram ini menunjukkan kelas-kelas obyek yang menyusun sistem serta relasi diantara kelas-kelas-kelas-kelas obyek. Obyek pada class diagram ini dapat disimpan dalam dua 2 kelas, yaitu:
¾ Kelas Persisten adalah sebuah kelas yang mendeskripsikan
obyek yang akan tetap ada meskipun eksekusi program sudah selesai dengan kata lain obyek tersebut disimpan secara permanen di dalam basis data.
¾ Kelas obyek Transien adalah sebuah kelas yang
mendeskripsikan obyek yang dibuat secara temporer dan hanya dikenali selama program dieksekusi.
2.4.2 Class Diagram Desain
Class diagram desain merupakan sebuah diagram yang menggambarkan kelas-kelas yang berhubungan dengan komponen software yang digunakan untuk membangun aplikasi software. Diagram kelas ini berisi:
a.Kelas.
b. Relasi asosiasi, generalization/specialization, dan agregasi. c.Informasi atribut dan tipe atribut.
d. Metode dengan parameter. e.Navigability.
f.Ketergantungan (dependensi).
2.5Sequence Diagram
Sequence diagram merupakan diagram UML yang memodelkan logika dari use case dengan menggambarkan interaksi pesan-pesan antara obyek dalam urutan waktu. Sequence diagram terdiri-dari beberapa bagian seperti yang terlihat pada Gambar 2.6.
Gambar 2.6 Sequence Diagram
Keterangan Gambar: 1. Actor
2. Interface class 3. Controller class 4. Entity classes
5. Messages 6. Activation bars 7. Return messages 8. Self-call 9. Frame 2.6Java
Java merupakan suatu bahasa pemrograman yang bersifat object-oriented, multi platform dan aman. Object-oriented merupakan suatu metode pengembangan perangkat lunak di mana sebuah program merupakan sekelompok objek yang bekerja bersama. Multi platform berarti dapat dijalankan di berbagai macam sistem operasi jika mempunyai interpreter Java yang dapat membaca bytecode.
2.6.1 Java 2 Platform Enterprise Edition (J2EE)
J2EE merupakan ekstensi dari J2SE(Java 2 Platform Standard Edition) yang membuat Java Enterprise API dapat berfungsi dan dapat diakses dengan cara diintegrasikan. J2EE digunakan untuk membangun aplikasi enterprise berskala besar dan mempunyai arsitektur multi-tier. Gambar 2.7 merupakan arsitektur J2EE.
Gambar 2.7 Arsitektur J2EE
2.6.2 JSP(Java Server Pages)
JSP merupakan salah satu komponen J2EE yang digunakan dalam pemrograman web sebagai penghubung antara HTML dan Java. JSP menggunakan HTTP sebagai protokol untuk melakukan komunikasi seperti meminta ke server dan merespon ke client. Hal ini yang membuat JSP menjadi teknologi Web yang ideal untuk digunakan.
Dalam arsitekturnya, JSP bergantung pada Java Servlet API dan implementasi. Walaupun JSP ditulis oleh pembangun aplikasi, tetapi pada akhirnya akan dikonversi ke Java Servlet. Implementasi kelas pada JSP sebenarnya mendasari representasi servlet pada JSP. Pembangun aplikasi dapat membuat komponen-komponen JSP menggunakan element yang sesuai untuk penyajian seperti HTML, XML, perintah-perintah JSP dan bahasa lainnya. Keuntungan yang dihasilkan oleh Java Servlet dan komponen JSP sama karena kedua
teknologi tersebut dilihat secara umum sebagai komponen Web dalam J2EE yang merupakan mekanisme untuk konfigurasi dan manajemen layanan. Gambar 2.8 beikut merupakan arsitektur JSP.
Gambar 2.8 Arsitektur JSP
2.7 SQL (Structured Query Language)
SQL merupakan suatu bahasa yang digunakan untuk mengakses basis data. SQL dapat digunakan untuk menjelaskan struktur dari suatu data, modifikasi data pada basis data dan menetapkan batasan keamanan. SQL mempunyai terbagi atas beberapa bagian, yaitu :
a. Data-Definition Language(DDL) yang menyediakan perintah untuk menjelaskan relasi, menghapus relasi dan memodifikasi relasi. DDL menyediakan perintah-perintah seperti :
1. CREATE nama_objek 2. ALTER nama_objek 3. DROP nama_objek
b. Data-Manipulation Language (DML) yang merupakan bahasa query berbasis relational algebra dan tuple relational calculus. DML menyediakan perintah-perintah seperti :
1. SELECT
Digunakan untuk membaca data dari basis data. Bentuk umum perintah ini adalah :
SELECT * | {[DISTINCT|DISTINCTROW] column | expression[alias], …}
FROM table
[WHERE condition(s)] [GROUP BY condition(s)] [HAVING condition(s)]
[ORDER BY condition(s) [ASC|DEC]]
2. INSERT
Digunakan untuk menambahkan satu atau lebih data dari basis data. Bentuk umum perintah ini adalah :
INSERT INTO table (column1, column2, [columnN]) VALUES (value1, value2, [valueN])
3. UPDATE
Digunakan untuk mengubah data pada satu atau lebih baris data pada tabel. Bentuk umum perintah ini adalah :
UPDATE table SET column1 = value1, column2 = value2, [columnN = valueN] [WHERE id_column = value]
4. DELETE
Digunakan untuk menghapus satu atau lebih data dari suatu tabel. Bentuk umum perintah ini adalah :
DELETE FROM tablename [where field1 = value1 [AND | OR] field2 = value2 [AND | OR] fieldN = valueN]
c. View-Definition yang merupakan bagian dari DDL yang menyediakan perintah view untuk melihat data dari satu tabel atau lebih.
d. Transaction control yang menyediakan perintah untuk memulai dan mengakhiri transaksi.
e. Embedded SQL yang menjelaskan di mana perintah SQL dapat diintegrasikan ke dalam bahasa pemrograman seperti C, C++, Java, Cobol, Pascal dan lain-lain.
f. Integrity yang merupakan bagian dari DDL yang menyediakan perintah untuk menspesifikasi integritas data yang masuk ke basis data.
g. Authorization yang merupakan bagian dari DDL yang menyediakan perintah untuk menspesifikasi aturan akses.
BAB III
ANALISIS DAN PERANCANGAN SISTEM
3.1Sistem yang Ada Saat Ini
Ketika pembeli ingin membeli barang komputer, maka pembeli akan langsung ke toko komputer untuk merakit komputer. Perakitan komputer dapat dilakukan oleh pembeli ataupun penjual. Setelah melakukan perakitan, maka penjual akan memberikan nota sebagai bukti transaksi. Proses ini kemudian dilanjutkan dengan pembayaran. Penjual kemudian mencatat proses penjualan ke buku penjualan. Toko juga dapat membantu pembeli untuk melakukan retur barang selama masa garansi masih berlaku. Rekap laporan penjualan dilakukan 1 minggu sekali.
Pada proses pembelian barang, nota pembelian yang diperoleh dari distributor akan dicatat ke dalam buku pembelian. Kemudian dari buku pembelian, akan dicatat stok barang yang bertambah sesuai dengan pembelian yang dilakukan. Rekap laporan pembelian dilakukan 1 minggu sekali.
3.2Sistem yang Akan Dibangun
Sistem akan melakukan proses bisnis dari toko secara komputerisasi meliputi pencatatan pembelian, penjualan, retur penjualan dan pencetakan laporan. Sistem dibangun dengan berbasis website. Sistem juga akan memberikan keleluasan bagi pembeli untuk melakukan perakitan komputer
melalui website. Setelah itu pembeli dapat mengambil barang dan melakukan pembayaran ke toko.
Selain membantu proses bisnis, pembeli atau pengunjung website juga dapat berinteraksi dengan penjual dengan memberi komentar atau pertanyaan. Pembeli atau pengunjung website juga dapat memperoleh berita terbaru seputar komputer.
3.3Diagram Konteks
Gambar 3.1 berikut merupakan diagram konteks sistem.
Gambar 3.1 Diagram Konteks
3.4Diagram Use case
Pegawai Pemilik Pembeli Log in Merakit Komputer Subsistem Komentar Mengisi komentar Menjawab komentar Menghapus komentar Subsistem Data Barang Mengisi data barang Mengubah data barang Menghapus data barang Subsistem Berita Mengisi berita Mengubah berita Menghapus berita Log out Cetak laporan <<depends on>> <<depends on>> <<depends on>> <<depends on>> <<depends on>> <<depends on>> Membuat account baru Menghapus account <<depends on>> Subsistem Data Pembelian
Mengisi data pembelian Mengubah data pembelian Menghapus data pembelian
Subsistem Data Penjualan
Mengubah status penjualan Menghapus data penjualan Mencatat retur barang <<depends on>> Mencari data barang Admin «extends» «extends» <<depends on>> <<depends on>>
3.4.1 Ringkasan Use case
Ringkasan use-case sistem yang memuat use-case, deskripsi dan pelaku yang berpartisipasi dapat dilihat pada :
Tabel 3.1 Ringkasan Use-case
No Nama Use-case Deskripsi Use-case Pelaku yang berpartisipasi 1 Log in Use case ini menggambarkan
proses untuk masuk ke sistem Administrasi
Pegawai , Pemilik (primary business)
2 Log out Use case ini menggambarkan proses untuk keluar ke sistem Administrasi
Pegawai , Pemilik (primary business)
3 Merakit komputer Use case ini menggambarkan proses merakit komputer dan memperoleh bukti transaksi
Pembeli (primary business)
4 Mengisi data pembelian
Use case ini menggambarkan proses pencatatan data barang yang telah dibeli dari distributor
Pegawai , Pemilik (primary business)
5 Mengubah data pembelian
Use case ini menggambarkan proses pengubahan data
pembelian. Proses ini dapat berupa penambahan data barang ataupun pengubahan detail data pembelian
Pegawai , Pemilik (primary business)
pembelian proses penghapusan data pembelian
business)
7 Mengubah status penjualan
Use case ini menggambarkan proses pengubahan status dari suatu penjualan
Pegawai , Pemilik (primary business)
8 Menghapus data penjualan
Use case ini menggambarkan proses penghapusan data penjualan
Pegawai , Pemilik (primary business)
9 Mengisi komentar Use case ini menggambarkan proses untuk pengisian komentar
Pembeli (primary business)
10 Menjawab komentar
Use case ini menggambarkan proses menjawab komentar yang telah diisi oleh Pembeli
Pegawai , Pemilik (primary business)
11 Menghapus komentar
Use case ini menggambarkan proses penghapusan komentar
Pegawai , Pemilik (primary business)
12 Mengisi berita Use case ini menggambarkan proses pengisian berita
Pegawai , Pemilik (primary business)
13 Mengubah berita Use case ini menggambarkan proses mengubah berita yang telah ada
Pegawai , Pemilik (primary business)
14 Menghapus berita Use case ini menggambarkan proses penghapusan berita
Pegawai , Pemilik (primary business)
barang proses penambahan data barang business) 16 Mengubah data
barang
Use case ini menggambarkan proses pengubahan data barang yang ada
Pegawai , Pemilik (primary business)
17 Menghapus data barang
Use case ini menggambarkan proses penghapusan data barang
Pegawai , Pemilik (primary business)
18 Mencari data barang
Use case ini menggambarkan proses pencarian data barang
Pegawai , Pemilik (primary business)
19 Cetak laporan Use case ini menggambarkan proses pencetakan laporan
Pegawai , Pemilik (primary business)
20 Membuat account baru
Use case ini menggambarkan proses pembuatan account baru untuk Pegawai
Pemilik (primary business)
21 Menghapus account Use case ini menggambarkan proses penghapusan data Pegawai
Pemilik (primary business)
22 Mencatat retur barang
Use case ini menggambarkan proses pencatatan barang yang akan diretur
Pegawai , Pemilik (primary business)
3.4.2 Narasi Use-case
Narasi Use-case Log in dapat dilihat pada : Tabel 3.2 Narasi Use-case Log in
Author : Johanes Taufan Sungkit
Date : 21 November 2008 Version : 1.0
Use-case Name: Log in Jenis Use-case
Use-case ID: DTK-001 Business Requirements: √
Priority: High Source: - Primary Business Actor: Pegawai, Pemilik Other Participating Actor: - Other Interested Stakeholder: -
Description: Use case ini menggambarkan proses masuk ke sistem Proses ini
berguna untuk menjaga keamanan dalam mengakses data.
Precondition: Pegawai / Pemilik telah memiliki password dan Pembeliname.
Trigger: Use case ini akan digunakan apabila ada Pegawai / Pemilik yang
akan mengakses atau melakukan manipulasi data. Typical Course
of event:
Actor Action System Response Step 1: Pegawai / Pemilik
mengakses halaman Log in. Step 3: Pegawai / Pemilik memasukkan username dan password.
Step 4: Pegawai / Pemilik mengklik tombol OK
Step 2: Sistem meminta Pegawai / Pemilik memasukkan username dan password.
Step 5: Sistem mengecek validasi username dan password di database. Step 6: Sistem masuk ke menu utama Admin.
Alternate Course:
Alt-Step 4: Pegawai tidak jadi memasukkan username dan password dengan mengklik tombol BATAL.
Alt-Step 5: Jika username dan password yang diinputkan tidak sesuai, maka sistem akan memberikan peringatan dan secara otomatis kembali ke halaman Log in.
Conclusion: Use case ini berhenti apabila Pegawai / Pemilik berhasil masuk ke
menu utama Pegawai.
Postcondition: • Pegawai / Pemilik berhasil masuk ke menu utama Admin.
• Pegawai / Pemilik tidak berhasil masuk ke menu utama Admin.
Business Rules: Pegawai / Pemilik memasukkan username dan password yang benar.
Implementation Constrains and
Narasi Use-case Log out dapat dilihat pada : Tabel 3.3 Narasi Use-case Log out
Specifications:
Assumptions: -
Open issues: Karena tidak hanya satu orang saja yang mengakses data-data yang
ada dikhawatirkan data yang harusnya tidak boleh dilihat oleh orang yang tidak memiliki wewenang pada akhirnya juga dapat dilihat.
Author : Johanes Taufan Sungkit
Date : 21 November 2008 Version : 1.0
Use-case Name: Log out Jenis Use-case
Use-case ID: DTK-002 Business Requirements: √
Priority: High Source: - Primary Business Actor: Pegawai, Pemilik Other Participating Actor: - Other Interested Stakeholder: -
Description: Use case ini menggambarkan proses keluar dari sistem Proses ini
berguna untuk menjaga keamanan setelah mengakses sistem.
Precondition: Pegawai / Pemilik telah Log in.
Trigger: Use case ini akan digunakan apabila ada Pegawai / Pemilik ingin
keluar dari sistem. Typical Course
of event:
Actor Action System Response Step 1: Pegawai / Pemilik
mengklik Log out.
Step 2: Sistem akan keluar. Alternate
Course:
-
Conclusion: Use case ini berhenti apabila Pegawai / Pemilik telah keluar dari
sistem.
Postcondition: Pegawai / Pemilik kembali ke menu Log in.
Business Rules: -
Implementation Constrains and Specifications:
Tampilan sistem berupa Web.
Assumptions: -
Narasi Use-case Merakit komputer dapat dilihat pada : Tabel 3.4 Narasi Use-case Merakit komputer
ada dikhawatirkan data yang harusnya tidak boleh dilihat oleh orang yang tidak memiliki wewenang pada akhirnya juga dapat dilihat.