BAB II LANDASAN TEORI

Transkripsi

1 BAB II LANDASAN TEORI 2.1. RESEP a. Pengertian Resep Resep adalah permintaan tertulis seorang dokter, dokter gigi atau tokter hewan yang diberi izin berdasarkan peraturan perundang-undangan yang berlaku kepada apoteker pengelola apotik untuk menyediakan dan menyerahkan obat-obatan bagi penderita. (Soetopo, 2002). Resep disebut juga formulae medicae, terdiri dari: 1. Formulae Officinalis, yaitu resep yang tercantum dalam buku farmakope atau buku lainnya dan merupakan standar. 2. Formulae Megistralis, yaitu resep yang ditulis oleh dokter. Resep selalu dimulai dengan tanda R/ yang diambil dari bahasa Latin, recipe yang berarti ambillah. Dibelakang tanda ini (R/) biasanya baru tertera nama dan jumlah obat. Umumnya resep ditulis dalam bahasa latin. Suatu resep yang lengkap harus memuat : 1. Nama, alamat dan nomor izin praktik dokter, dokter gigi atau dokter hewan. 2. Tanggal penulisan resep, nama setiap obat atau komposisi obat. 3. Tanda R/ pada bagian kiri setiap penulisan resep. 4. Tanda tangan atau paraf dokter penulis resep sesuai dengan peraturan perundang-undangan yang berlaku. 7

2 5. Nama pasien, jenis kelamin (manusia/hewan). Umur serta alamat pasien/pemilik hewan. 6. Tanda seru dan paraf dokter untuk resep yang mengandung obat yang jumlahnya melebihi dosis maksimal. Dr. S.H. xxxxxx DSP/xxxx/xx.x/xxx Alamat Dokter Waktu praktik dokter R/ Extr. Bellad 120 mg HCl Ephed 300 mg C.T.M 50 mg Doveri Pulv. 3 O.B.H 300 ml m.f. potio s.t.d.d. C Pro : Nama pasien Umur : umur pasien Alamat : alamat pasien Jakarta, 20 mei 2000 Paraf dokter Gambar 2.1 Contoh Resep Dokter (Soetopo, 2002) Pembagian suatu resep yang lengkap : 1. Tanggal dan tempat ditulisnya resep(inscriptio). 2. Aturan pakai dari obat yang tertulis(signatura). 3. Paraf/tanda tangan dokter yang menulis resep (subcriptio). 4. Tanda buka penulisan resep dengan R/ (invocatio). 5. Nama obat, jumlah dan cara membuatnya (praescriptio atau ordinatio). Yang berhak menulis resep adalah : 1. Dokter umum/khusus. 8

3 2. Dokter gigi, terbatas pada pengobatan gigi dan mulut. 3. Dokter hewan, terbatas pada pengobatan hewan. Dokter gigi diberi ijin menulis resep dari segala macam obat untuk pemakaian mulut. Injeksi (parental) atau cara pemakaian lainnya. Khusus untuk mengobati penyakit gigi dan mulut. Sedangkan pembiusan/patirasa sevcara umum tetap dilarang bagi dokter gigi (S.E) Depkes No. 19/Ph/62 Mei 1962 Untuk penderita yang memerlukan pengobatan segera dokter dapat memberi tanda : a. Cito : Segera. b. Urgent : penting. c. Statim : penting d. P.I.M : Periculum In Mora (berbahaya bila ditunda) Pada bagian kanan atas resep, apoteker harus mendahulukan pelayanan resep ini termasuk ini resep antidotum(anti racun). Bila dokter ingin agar resepnya dapat diulang, maka dalam resep ditulis Iteratie, dan ditulis berapa kali resep boleh diulang. Misalkan Iteratie 3X, artinya resep dapat dilayani kali ulangan. Untuk resep yang mengandung narkotika, tidak dapat ditulis iteratie tetapi selalu dengan resep baru. b. Salinan Resep (Copy Resep) Salinan resep adalah salinan yang dibuat apotik, selain memuat semua keterangan yang terdapat dalam resep asli, juga harus memuat : 9

4 1. Nama dan alamat Apotik. 2. Nama dan nomor izin apoteker pengelola apotik. 3. Tanda tangan atau paraf apoteker pengelola apotik. 4. Tanda det (detur) untuk obat yang sudah diserahkan dan tanda nedet (nedetur) untuk obat yang belum diserahkan, pada resep dengan tanda ITER...X diberi tanda detur orig/detur...x. 5. Nomor resep dan tanggal pembuatan. NAMA APOTIK Alamat APOtik Nama Apoteker Nomr Izin Apoteker Salinan Resep No Dari dokter Ditulis tanggal Pro : xx : Nama Dokter : xx/xx/xxxx : Nama pasien R/ Amoxycillin 500 No XII S.3.d.d.I R/ Ponstan FCT No XII S.p.r.n.I det ne det Jakarta, 5 November 2001 Cap Apotik pcc Tanda tangan APA Gambar 2.2 Contoh Salinan Resep (Soetopo, 2002) Istilah lain dari copy resep adalah apograph, exemplum, afschrif. Apabila apoteker pengelola apotik (APA) berhalangan melalukan tugasnya, penandatanganan atau pencantuman paraf pada salinan resep yang dimaksud di atas dilakukan oleh Apoteker Pendamping atau Apoteker Pengganti dengan mencantumkan nama terang dan status yang bersangkutan. 10

5 Salinan resep hanya boleh diperlihatkan kepada : 1. Dokter penulis resep atau yang merawat penderita. 2. Penderita sendiri. 3. Petugas kesehatan atau petugas lain yang berwenang menurut perundang-undangan yang berlaku. Sebagai contoh: petugas pengadilan bila diperlukan untuk suatu perkara. c. Penyimpanan Resep Apoteker Pengelola Apotik (APA) mengatur resep yang telah dikerjakan menurut urutan tanggal dan nomor urut penerimaan resep. Resep harus disimpan sekurang-kurangnya selama 3 tahun. Resep yang mengandung narkotika harus dipisahkan dari resep lainnya. Resep yang disimpan melebihi jangka 3 tahun dapat dimusnahkan. Pemusnahan resep dilakukan dengan cara dibakar atau dengan cara lain yang memadai oleh Apoteker Pengelola Apotik bersama-sama dengan sekurang-kurangnya seorang petugas apotik. Pada pemusnahan resep harus dibuat berita acara pemusnahan sesuai dengan bentuk yang telah ditentukan, rangkap 4 dan ditanda-tangani oleh APA bersama dengan sekurang-kurangnya seorang petugas apotik. Apoteker tidak dibenarkan mengulangi penyerahan obat atas dasar resep yang sama apabila pada resep aslinya tercantum : 1. Tanda n.i (ne iteratur = Tidak boleh diulang) 2. Obat narkotika atau obat lain yang tidak boleh diulang tanpa resep baru dari dokter. 11

6 2.2. QR CODE Bar code telah banyak dikenal dan digunakan secara luas karena kecepatan pada saat pembacaan, keakuratan, dan karakteristik penggunaannya secara luas. Di saat bar code banyak dikenal dan dapat digunakan secara universal, pasar mulai mencari kode yang dapat menyimpan lebih banyak informasi, tipe karakter yang dapat digunakan, dan dapat dicetak dengan ukuran yang lebih kecil. Sebagai akibatnya, banyak usaha yang dilakukan untuk menambahkan jumlah informasi yang dapat disimpan dengan menggunakan bar code, seperti dengan menambahkan digit bar code atau meletakkan beberapa bar code. Bagaimanapun, perbaikan ini pun menyebabkan timbulnya beberapa masalah, seperti bertambahnya ukuran bar code, proses pembacaan yang rumit, dan peningkatan ongkos pencetakan. 2D (2 Dimensional) Code muncul sebagai respon untuk kebutuhan dan masalah-masalah di atas. 2D Code juga merupakan hasil pengembangan dari bar code yang dibatangkan, untuk menambah kerapatan informasi metode matrix. Gambar 2.3 Bar code dengan beberapa susunan. (Anonymus, 2009) Gambar 2.4 2D Code dengan bar code batangan (Anonymus, 2009) 12

7 Gambar 2.5 2D Code (tipe matrix) (Anonymus, 2009) QR Code merupakan salah satu jenis dari 2D Code yang dikembangkan oleh Denso Wave (salah satu divisi dari Denso Corporation) dan dirilis pada tahun 1994 dengan tujuan utama sebagai simbol yang dapat diinterpretasikan secara mudah oleh peralatan scanner (Anonymus, 2009). Gambar 2.6 Perbandingan QRCode dan Barcode (Anonymus, 2009) QR Code mengandung informasi secara dua arah, vertical dan horizontal, sedangkan sebuah bar code hanya mengandung data pada satu arah. QR Code dapat menyimpan informasi lebih banyak bila dibandingkan dengan bar code (Anonymus, 2009). Selain itu, QR Code memiliki beberapa keunggulan lain, diantaranya : a. Kecepatan yang tinggi pada saat pembacaan b. Kerapatan yang tinggi c. Koreksi kesalahan d. Penyususan terstruktur 13

8 Informasi versi Informasi format Data dan kunci error correction Pola yang diperlukan Posisi baca Perataan Timing Gambar 2.7 Struktur QRCode (Anynomus, 2009) Karakter karakter yang dapat disandikan ke dalam QR Code ada beberapa macam, antara lain: a. Numeric (0-9), 3 karakter dapat disandikan sepanjang 10 bit. Secara teori, jumlah maksimum karakter yang dapat ditampung bisa mencapai 7089 karakter b. Alphanumeric (0-9,A-Z,%,$,*,+,-,/:), 2 karakter dapat disandikan sepanjang 11 bit. Secara teori, jumlah maksimum karakter yang dapat ditampung bisa mencapai 4296 karakter. c. KANJI, sebuah karakter KANJI (karakter multi byte) dapat disandikan sepanjang 13 bit. Secara teori, jumlah maksimum karakter yang dapat ditampung bisa mencapai 1817 karakter. QR Code memiliki kemampuan error correction dalam memulihkan data bila rusak atau kotor. Tersedia 4 tingkatan untuk koreksi kesalahan yang dapat dipilih oleh pengguna bergantung pada lingkungan penggunaan. Semakin tinggi tingkatannya, maka semakin baik pula kemampuan koreksinya, namun ukurannya menjadi lebih besar (Anonymus, 2009). Untuk memilih tingkatan koreksinya, ada beberapa hal yang dapat dijadikan sebagai 14

9 bahan pertimbangan, seperti ruang lingkup penggunaan, serta ukuran yang dibutuhkan. Tabel 2.1 Error Correction Level Pada QRCode (Anonymus, 2009) Tingkatan / Level Tingkat Kerusakan Yang Dapat Dipulihkan L Maksimal 7% M Maksimal 15% Q Maksimal 25% H Maksimal 30% Level Q atau H dapat digunakan untuk lingkungan produksi yang memungkinkan QR Code menjadi kotor, sedangkan level L dapat digunakan untuk lingkungan yang bersih dengan kapasitas data yang besar. Pada umumnya level M paling banyak digunakan Basis Data Basis data adalah kumpulan data yang saling berhubungan secara logis, dan informasi yang terkandung di dalamnya dirancang agar dapat memberikan informasi yang dibutuhkan sebuah organisasi (Connolly, 2005). Istilah "basis data" berawal dari ilmu komputer. Catatan yang mirip dengan basis data sebenarnya sudah ada sebelum revolusi industri yaitu dalam bentuk buku besar, kuitansi dan kumpulan data yang berhubungan dengan bisnis. 15

10 Konsep dasar dari basis data merupakan kumpulan dari catatan-catatan, atau potongan dari pengetahuan. Sebuah basis data memiliki penjelasan terstruktur dari jenis fakta yang tersimpan di dalamnya dan penjelasan ini disebut skema basis data (Connolly, 2005). Skema menggambarkan obyek yang diwakili suatu basis data, dan hubungan di antara obyek tersebut. Ada banyak cara untuk mengorganisasi skema, atau memodelkan struktur basis data: ini dikenal sebagai model basis data atau model data. Model yang umum digunakan sekarang adalah model relasional, yang mewakili semua informasi dalam bentuk tabel-tabel yang saling berhubungan di mana setiap tabel terdiri dari baris dan kolom. Dalam model ini, hubungan antar tabel diwakili dengan menggunakan nilai yang sama antar tabel. Model yang lain seperti model hierarki dan model jaringan menggunakan cara yang lebih eksplisit untuk mewakili hubungan antar tabel. Istilah basis data mengacu pada koleksi dari data-data yang saling berhubungan, dan perangkat lunaknya seharusnya mengacu sebagai sistem manajemen basis data (database management system/dbms). DBMS merupakan sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, mengatur, dan mengontrol akses pada sebuah basis data (Connolly, 2005). Basis data merupakan komponen utama sistem informasi karena semua informasi untuk pengambilan keputusan berasal dari data di basis data. Pengelolaan basis data yang buruk dapat mengakibatkan ketidaktersediaan data penting yang digunakan untuk menghasilkan informasi yang diperlukan dalam pengambilan keputusan. 16

11 Salah satu tahap utama dalam membangun sebuah sistem basis data adalah perancangan basis data. Dalam tahapan ini terdapat tiga fase utama, yaitu: desain konseptual, desain logis, dan desain fisik. Desain konseptual basis data dibuat untuk memberikan gambaran basis data secara konseptual, yang di dalamnya terdapat identifikasi dari entitas entitas penting, hubungan, dan atribut atribut. Desain logis basis data dibuat untuk menterjemahkan gambaran konseptual tadi menjadi struktur logis dari basis data, yang di dalamnya terdapat desain dari hubungan hubungan. Desain fisik basis data dibuat agar dapat diputuskan bagaimana desain logis tadi dapat diimplementasikan secara fisik (menjadi basis hubungan) ke dalam DBMS tujuan (Connolly, 2005). a. Metodologi Perancangan Konseptual Basis Data Metodologi perancangan basis data adalah sebuah pendekatan terstruktur yang menggunakan prosedur prosedur, teknik teknik, peralatan, dan bantuan dokumentasi untuk mendukung dan menfasilitasi proses perancangan (Connolly, 2005). Dalam perancangan konseptual basis data metodologi yang digunakan merupakan proses penciptaan sebuah model dari data yang digunakan dalam sebuah organisasi, terlepas dari semua pertimbangan pertimbangan secara fisik. Model data adalah sekumpulan konsep yang terintegrasi untuk menggambarkan dan menggunakan data, hubungan hubungan antar data, dan pembatas pada data dalam sebuah organisasi (Connolly, 2005). Model data konseptual didukung oleh dokumentasi, termasuk hubungan entitas dan kamus data, yang dibuat untuk seluruh pengembangan model. Rincian 17

12 dari tipe tipe dokumentasi penunjang mungkin saja dibuat pada saat melewati bermacam macam langkah. Tugas yang terkait dalam langkah langkah tersebut adalah: 1. Mengenali tipe tipe entitas yang digunakan. 2. Mengenali tipe tipe hubungan penting yang ada di antara tipe tipe entitas tadi 3. Mengenali dan menghubungkan atribut atribut dengan entitas atau tipe tipe hubungan yang tepat. 4. Menentukan domain domain untuk atribut atribut yang terdapat di dalam model data konseptual local. Domain merupakan sekumpulan nilai dari salah satu atau lebih atribut yang mengambil nilainya. 5. Mengenali kunci kandidat untuk setiap tipe entitas, bila terdapat lebih dari satu kunci kandidat, maka salah satunya dipilih untuk menjadi kunci utama dan sisanya menjadi kunci alternatif. Ketika memilih kunci utama diantara kunci kunci kandidat, dapat mempetimbangkan petunjuk petunjuk berikut: a.) Pilih kunci kandidat yang memiliki sedikit atribut.. b.) Pilih kuncu kandidat yang tidak mudah berubah nilainya. c.) Pilih kunci kandidat dengan karakter paling sedikit (bila atributnya berupa karakter). d.) Pilih kunci kandidat dengan nilai maksimum paling sedikit.(bila atributnya berupa bilangan) e.) Pilih kunci kandidat yang paling mudah digunakan dari sudut pandang pengguna. 18

13 6. Mempertimbangkan penggunaan model konsep yang lebih baik, seperti spesialisasi/generalisasi, agregasi, dan komposisi. 7. Memeriksa apakah ada redundansi di dalam model. 8. Memvalidasi model konseptual terhadap transaksi pengguna untuk memastikan bahwa model tersebut mendukung transaksi yang dibutuhkan. 9. Mereview model data konseptual bersama pengguna untuk memastikan bahwa kunci mempertimbangkan model agar menjadi representasi yang sebenarnya dari kebutuhan data organisasi. Perancangan basis data konseptual merupakan proses menyusun model dari informasi yang digunakan dalam sebuah organisasi yang tidak bergantung pada detail implementasi, seperti DBMS tujuan, program aplikasi, bahasa pemrograman, atau pertimbangan bersifat fisik lainnya (Connolly, 2005). Tujuan utama dari tahapan ini adalah untuk membuat sebuah model konseptual dari kebutuhan data organisasi. Model data konseptual terdiri dari, entity type, relationship type, attributes, attributes domain, primary key, dan alternate key. Tipe entitas (entity type) merupakan sekumpulan objek yang memiliki sifat yang sama, yang dapat diidentifikasi dalam sebuah organisasi yang tidak memiliki keterikatan (Connolly, 2005). Konsep dasar dari model Entity Relational (ER) adalah tipe entitas, yang mewakili sekumpulan objek di dunia nyata dengan sifat yang sama. Sebuah entity type tidak memiliki keterikatan (independent) dan bisa merupakan 19

14 objek dengan keberadaan fisik (atau nyata) atau objek yang bersifat konseptual (abstrak). Tipe hubungan (relationship type) adalah sekumpulan hubungan yang memiliki arti di antara tipe tipe entitas (Connolly, 2005). Setiap tipe hubungan diberikan nama yang menggambarkan fungsinya. Model ER menggunakan level abstraksi yang lebih tinggi bila dibandingkan dengan semantic net dengan mengkombinasikan sebuah set entity occurrence dan entity types dan sebuah set relationship occurrence dan relationship type. Keterangan mengenai sifat sifat dari entity type disebut sebagai atribut (Connolly, 2005). Atribut memiliki nilai yang menggambarkan setiap entity occurence dan mewakili bagian utama dari data yang disimpan di dalam basis data. Sebuah relationship type yang terhubungan entitas dapat juga memiliki atribut yang mirip dengan atribut yang dimiliki entity type. Sedangkan attributes domain merupakan sekumpulan nilai yang diizinkan untuk satu atau lebih atribut. Setiap atribut terikat dengan sekumpulan nilai yang disebut domain. Domain mendifinisikan nilai nilai potensial yang dapat dimiliki oleh sebuah atribut dan serupa dengan konsep domain dalam model relasional. Sebuah candidate key merupakan beberapa atribut dalam jumlah minimum, yang nilainya dapat mengidentifikasi secara unik setiap entity occurrence. Candidate key harus memiliki nilai yang unik untuk setiap occurrence dari entity type. Hal ini menyatakan bahwa sebuah candidate key tidak dapat kosong. Setiap entity type mungkin saja memiliki lebih 20

15 dari satu candidate key. Candidate key yang dipilih agar dapat mengidentifikasi occurrence dari entity type secara unik disebut primary key (Connolly, 2005). Entity occurrence merupakan sebuah objek dari entity type yang dapat diidentifikasi secara unik. Entity type dapat diidentifikasi dengan sebuah nama dan daftar sifat sifatnya. Sebuah basis data secara normal mengandung banyak entity type yang berbeda. Sedangkan relstionship occcurence merupakan association yang dapat diidentifikasi secara unik, yang berisikan satu occurence dari setiap entity type yang ada. b. Metodologi Perancangan Logis Basis Data Perancangan logis basis data dilakukan dengan membuat dan memvalidasi model data logis, hal ini bertujuan untuk menterjemahkan model data konseptual menjadi model data logis lalu model tersebut divalidasi untuk memeriksa apakah susunannya sesuai dan dapat menunjang transaksi yang dibutuhkan (Connolly, 2005). Langkah langkah yang termasuk di dalamnya adalah 1. Membuat relasi untuk model data logis untuk menggambarkan entitas, relationship, dan atribut yang telah diidentifikasi. 2. Memvalidasi relasi di dalam model data menggunakan normalisasi. 3. Memastikan bahwa lreasi di dalam model data logis mendukung transaksi yang dibutuhkan. 4. Memeriksan keutuhan constraint yang digambarkan dalam model data logis. 21

16 5. Bersama user memeriksa kembali model data logis untuk memastikan bahwa mempertimbangkan model yang dapat menggambarkan kebutuhan data organisasi yang sebenarnya. 6. Menggabungkan beberapa model data logis lokal menjadi sebuah model data logis global yang mewakili seluruh gambaran user terhadap basis data. 7. Memeriksa adanya perkembangan di masa yang akan datang untuk memastikan bila ada perubahan yang nyata dan dapat diketahui di masa yang akan datang dan untuk menilai apakah model data tersebut dapat mengakomodasi perubahan tersebut. Perancangan basis data secara logik dimulai dengan penciptaan model konseptual dari organisasi dan seluruhnya tak bergantung rincian implementasi seperti perangkat lunak DBMS, program aplikasi, bahasa pemrograman, platform perangkat keras, dan pertimbangan fisik lainnya. Model konsep ini kemudian dipetakan menjadi model data secara logik yang telah dipengaruhi model data target basis data seperti model relasional. Dalam perancangan basis data secara logik, kita dapat melakukannya dengan cara : 1. Menerapkan normalisasi terhadap struktur tabel yang telah diketahui. 2. Langsung membuat model Entity-Relationship (ER). Model data secara logik merupakan sumber informasi perancangan fisik. Model ini menyediakan perancang suatu kendaraan untuk pertimbangan dalam merancang basis data yang efisien. 22

17 c. Metodologi Perancangan Fisik Basis Data Perancangan fisik basis data merupakan proses menciptakan gambaran dari pengimplementasian basis data pada media penyimpanan kedua yang menggambarkan basis relasi, pengorganisasian file, dan indeks indeks yang digunakan agar menghasilkan akses data yang efisien, dan pembatas utuh lainnya yang terhubungan serta ukuran keamanan (Connolly, 2005). Fase perancangan fisik basis data mengizinkan perancang untuk membuat keputusan mengenai bagaimana basis data akan diimplementasikan. Oleh karena itu, desain fisik basis data dibuat khusus untuk DBMS tertentu. Ada umpan balik antara desain fisik dan desain konseptual/logis, karena keputusan yang diambil selama perancangan fisik digunakan untuk memperbaiki kemampuan yang mungkin berpengaruh kepada struktur model konseptual/logis. Ada beberapa faktor kritis agar tahapan perancangan basis data berhasil, contohnya seperti, bekerja secara interaktif dengan pengguna dan mau mengulangi langkah - langkahnya. Perancangan basis data relasional dimulai dari perancangan basis data logik untuk basis data relasional pada tahap 1 sampai dengan tahap 3, lalu dilanjutkan dengan perancangan dan implementasi basis data fisik untuk basis data relasional pada tahap 4 sampai dengan tahap 7. 1.) Tahap 1, membangun rancangan data konseptual lokal berdasarkan pandangan pemakai. Yaitu mengidentifikasikan himpunan entitas - himpunan entitas. Mengidentifikasikan keterhubungan-keterhubungan 23

18 (relationship), mengidentifikasikan dan asosiasikan atribut-atribut pada entitas atau keterhubungan, menentukan domain atribut, menentukan atribut-atribut candidate key dan primary key, melakukan spesialisasi/generalisasi, menggambarkan diagram ER, melakukan review model data konsep dengan pemakai. 2.) Tahap 2, membangun dan validasi model data logik lokal. Yaitu memetakan model data konsep ke model data logik, melakukan turunan relasi-relasi dari model data logik, validasi model menggunakan normalisasi, validasi model berdasarkan transaksi - transaksi pemakai, menggambarkan ER nya, mendefinisikan kontsrain - konstrain (batasan - batasan) integritas, melakukan review model data logik dengan pemakai. 3.) Tahap 3, membangun dan validasi model data logik global. Yaitu menggabungkan model data logik lokal menjadi model global, validasi model data logik global, periksa untuk pertumbuhan masa datang, menggambarkan diagram ER akhir, melakukan review model logik global dengan pemakai. 4.) Tahap 4, menerjemahkan model data logik global untuk DBMS target. Yaitu merancang relasi-relasi basis untuk DBMS target, merancang aturan-aturan integritas untuk DBMS target. 5.) Tahap 5, Merancang dan implementasi representasi fisik. Yaitu menganalisa transaksi-transaksi, memilih organisasi file, memilih indeksindeks sekunder, mempertimbangkan penambahan redudansi yang terkendali, estimasikan ruang disk yang diperlukan. 24

19 6.) Tahap 6, merancang dan mengimplementasikan mekanisme pengamanan. Yaitu merancang view - view pemakai, merancang aturan-aturan pengaksesan. 7.) Tahap 7, memonitor dan menyesuaikan system yang sedang operasi d. Normalisasi Normalisasi adalah sebuah tekhnik untuk menghasilkan sekumpulan relasi dengan property yang diharapkan, dan memberikan kebutuhan data sebuah organisasi (Connolly, 2005). Tujuan dari normalisasi adalah untuk mengidentifikasi sekumpulan relasi yang sesuai yang mendukung kebutuhan data sebuah organisasi. Ciri ciri sekumpulan data tersebut meliputi hal hal berikut: 1. Sedikitnya jumlah atribut yang dibutuhkan untuk mendukung kebutuhan data. 2. Atribut dengan yang mendekati relationship logis (digambarkan sebagai ketergantungan fungsional) ada pada relasi yang sama. 3. Sedikitnya redundancy (keterulangan) dengan masing masing atribut diwakilkan hanya sekali dengan pengecualian penting untuk atribut yang membentuk semua atau sebagian foreign key, yang sangat penting untuk menggabungkan relasi yang berhubungan. Keuntungan yang dengan menggunakan basis data yang memiliki sekumpulan relasi yang sesuai menyebabkan basis data lebih mudah bagi 25

20 pengguna untuk mengakses dan mengelola data, dan hanya memakan sedikit ruang penyimpanan di dalam komputer. Konsep penting yang terkait dengan normalisasi adalah functional dependency (ketergantungan fungsional), yang menggambarkan hubungan antar atribut(connolly, 2005). Functional dependency menggambarkan hubungan antar atribut dalam sebuah relasi. Sebagai contoh, bila A dan B adalah atribut dari relasi R, maka B tergantung secara fungsional pada A bila setiap nilai A terhubung dengan satu nilai B. Ketika ada sebuah functional dependency maka ketergantungan tersebut ditetapkan sebagai sebuah constraint antar atribut atribut, dan atribut atau grup atribut di sisi lainnya disebut determinant. A B functional dependency pada A A merupakan determinant B B Gambar 2.8. Diagram functional Dependency dan determinant. (Connolly, 2005) Teknik normalisasi melibatkan serangkaian aturan yang dapat digunakan untuk menguji relasi individual sehingga basis data dapat dinormalisasi ke berbagai tingkat. Ketika kebutuhan yang diinginkan tidak didapatkan, relasi yang melanggar kebutuhan harus didekomposisi menjadi relasi yang secara individu memenuhi kebutuhan normalisasi. Tiga bentuk normal yang awalnya diusulkan disebut First Normal Form/1NF (Bentuk Normak Pertama), Second Normal Form/2NF (Bentuk 26

21 Normal Kedua), dan Third Normal Form/3NF (Bentuk Normal Ketiga). Kemudian, R. Boyce and E.F Codd memperkanalkan definisi yang lebih kuat dari 3NF yang disebut Boyce-Codd Normal Form/BCNF (Connolly, 2005). Bentuk normal lebih tinggi Gambar 2.9. Diagram ilustrasi relasi antar bentuk normal (NF). (Connolly, 2005) Dengan mengesampingkan 1NF, semua bentuk normal ini berdasarkan ketergantungan fungsional di antara atribut atribut dalam sebuah relasi. Bentuk normal yang lebih tinggi ada setelah BCNF telah diperkenalkan seperti Fourth Normal Form/4NF (Bentuk Normal Keempat) dan Fifth Normal Form/5NF (Bentuk Normal Kelima). Namun, kedua bentuk normal terakhir tersebut sangat jarang dipergunakan dalam sebuah situasi. Normalisasi diawali dengan proses memindahkan data dari sumbernya ke dalam bentuk tabel dengan baris dan kolom. Dalam format ini, tabel masih dalam bentuk Unnormalized Form yang mengarah pada unormalized tabel. 1NF merupakan relasi yang pada setiap persimpangan 27

22 masing masing baris dan kolom hanya memiliki satu dan hanya satu nilai. Sedangkan 2NF merupakan sebuah relasi yang berada pada 1NF dan setiap atribut non-primary-key bergantung sepenuhnya secara fungsional pada primary-key. Walaupun relasi 2NF memiliki redundansi yang lebih sedikit dibandingkan 1NF, namun masih mengalami kesulitan pada saat perubahan anomali. Sedangkan 3NF adalah sebuah relasi yang ada pada 1NF dan 2NF dan tidak ada non-primary-key yang melengkapi ketergantungan pada primary-key. Normalisai dari 2NF ke 3NF melibatkan penghilangan ketergantungan transitif. Untuk mengetahui apakah sebuah relasi berada dalam bentuk BCNF, kita dapat mengenali semua determinant dan memastikan bahwa itu adalah candidate key. Panggil ulang determinan yang merupakan atribut, atau sekelompok atribut, yang pada atribut lainnya bergantung penuh secara fungsional. BCNF merupakan relasi yang, jika dan hanya jika, setiap determinan merupakan candidate key. BCND memliki efektifitas yang maksimal, dan kemungkinan terjadinya redundancy data dan duplikasi data lebih kecil daripada 1NF. Di atas BCNF masih ada 4NF yang merupakan bentuk normal lebih kuat yang mencegah sebuah relasi memiliki ketergantungan antar atribut. Dan lebih atas lagi ada 5NF yang merupakan sifat sifat dekomposisi yang dapat memastikan bahwa tidak ada tupel palsu yang dibuat ketika relasi digabungkan ulang melalui operasi penggabungan alami, sehingga dapat disimpulkan bahwa relasi ini tidak memiliki join 28

23 dependency. Join dependency menggambarkan sebuah tipe ketergantungan yang, jika dan hanya jika, nilai legal sebuah relasi sama dengan proyeksi gabungan atribut atributnya Metodologi Rekayasa Perangkat Lunak Sejarah munculnya Rekayasa Perangkat Lunak sebenarnya dilatarbelakangi oleh adanya krisis perangkat lunak (software crisis) di era tahun 1960-an. Krisis perangkat lunak merupakan akibat langsung dari lahirnya komputer generasi ke 3 yang canggih, ditandai dengan penggunaan Integrated Circuit (IC) untuk komputer. Performansi hardware yang meningkat, membuat adanya kebutuhan untuk memproduksi perangkat lunak yang lebih baik. Akibatnya perangkat lunak yang dihasilkan menjadi menjadi beberapa kali lebih besar dan kompleks. Pendekatan informal yang digunakan pada waktu itu dalam pengembangan perangkat lunak, menjadi tidak cukup efektif (secara cost, waktu dan kualitas). Biaya hardware mulai jatuh dan biaya perangkat lunak menjadi naik cepat. Karena itulah muncul pemikiran untuk menggunakan pendekatan engineering yang lebih pasti, efektif, standard dan terukur dalam pengembangan perangkat lunak. Kalimat seluruh aspek produksi perangkat lunak membawa implikasi bahwa bahwa Rekayasa Perangkat Lunak tidak hanya berhubungan dengan masalah teknis pengembangan perangkat lunak tetapi juga kegiatan strategis seperti manajemen proyek perangkat lunak, penentuan metode dan proses 29

24 pengembangan, serta aspek teoritis, yang kesemuanya untuk mendukung terjadinya produksi perangkat lunak. Kemudian tidak boleh dilupakan bahwa secara definisi perangkat lunak tidak hanya untuk program komputer, tetapi juga termasuk dokumentasi dan konfigurasi data yang berhubungan yang diperlukan untuk membuat program beroperasi dengan benar. Dengan definisi ini otomatis keluaran (output) produksi perangkat lunak disamping program komputer juga dokumentasi lengkap berhubungan dengannya. Ini yang kadang kurang dipahami oleh pengembang, sehingga menganggap cukup memberikan program yang jalan (running program) ke pengguna (customer). Dalam rekayasa perangkat lunak ini terdapat beberapa tahapan yang secara sederhana dapat digambarkan sebagai analisa kebutuhan, desain, implementasi, pengujian dan perawatan. Namun, dalam kenyataannya hal hal tersebut bisa menjadi sangat kompleks. Sebagai contoh, pada fase desain biasanya dibagi secara umum menjadi, desain arsitektur dan desain secara detail, dan seringkali bermacam fase pengujian dapat dibedakan..komponen dasar lainnya walau bagaimanapun, harus dilalui dalam setiap proyek. Metodologi adalah cara sistematis atau cara yang didefinisikan dengan jelas untuk mencapai tujuan akhir. Bagian awal dari rekayasa perangkat lunak adalah pemodelan karena hal ini akan mempengaruhi pekerjaan dalam rekayasa perangkat lunak tersebut. Salah satu model proses yang secara umum digunakan dalam pengembangan rekayas perangkat lunak adalah model Waterfall. 30

25 Pendekatan model waterfall berisi rangkaian aktivitas proses yang disajikan dalam proses yang terpisah, mulai dari tahap awal requirement capturing (analisa kebutuhan pengguna), specification (menentukan spesifikasi dari kebutuhan pengguna), desain, coding, testing sampai pemeliharaan sistem setelah digunakan (Vliet, 2002). COMMUNICATION Project initiation Requirement gathering PLANNING Estimating Scheduling Tracking MODELLING Analysis Design CONSTRUCTION Code Test DEPLOYMENT Delivery Support Feedback Gambar Skema Waterfall (Pressman, 2005) Proses pengumpulan kebutuhan diintesifkan dan difokuskan, khususnya pada perangkat lunak. Untuk memahami sifat program yang dibangun, perekayasa perangkat lunak harus memahami domain informasi, tingkah laku, unjuk kerja, dan antar muka (interface) yang diperlukan. Kebutuhan baik untuk sistem maupun perangkat lunak didokumentasikan dan dilihat lagi bersama pengguna. Setelah didapat kebutuhan - kebutuhan yang diperlukan melalui fase analisa kebutuhan, diperlukan adanya pemodelan sistem untuk menentukan proses yang melayani kebutuhan dengan mempertimbangkan data data yang 31

26 didapat saat analisa kebutuhan. Fase ini disebut juga fase desain yang merupakan fase penting, di mana pada saat pertama kali memutuskan untuk membuat sebuah desain memiliki pengaruh yang sangat besar pada kualitas perangkat lunak yang akan dibuat. Fase ini menghasilkan spesifikasi teknis yang menyajikan titik awal untuk fase implementasi. Desain perangkat lunak sebenarnya adalah proses multi langkah yang berfokus pada empat atribut sebuah program yang berbeda; struktur data, arsitektur perangkat lunak, representasi interface, dan detail (algoritma) / procedural. Proses desain menterjemahkan syarat / kebutuhan ke dalam sebuah representasi perangkat lunak yang dapat diperkirakan demi kualitas perangkat lunak sebelum dimulai pemunculan kode. Sebagai persyaratan, desain didokumentasikan dan menjadi bagian dari konfigurasi perangkat lunak. Desain harus diterjemahkan ke dalam bentuk mesin yang bisa dibaca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis. Sekali kode dibuat, pengujian program dimulai. Proses pengujian berfokus pada logika internal perangkat lunak, memastikan bahwa semua pernyataan sudah diuji, dan pada eksternal fungsional yaitu mengarahkan pengujian untuk menemukan kesalahan kesalahan dan memastikan bahwa input yang dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan. Pemeliharaan meliputi pengkoreksian kesalahan yang tidak ditemukan pada langkah sebelumnya. Perbaikan implementasi unit sistem dan peningkatan jasa sistem sebagai kebutuhan baur ditemukan. Masalah yang ada 32

27 dalam penggunaan model Waterfall ini adalah partisi yang tidak dapat diubah dari proyek ke tingkat yang berbeda. Pengiriman sistem terkadang tidak dapat dipaksakan. Meskipun begitu, model Waterfall ini menggambarkan teknis yang praktis. a. Unified Modelling Language Unified Modelling Language(UML) adalah bahasa standar untuk melakukan spesifikasi, visualisasi, kostruksi, dan dokumentasi dari komponen komponen perangkat lunak, dan digunakan untuk pemodelan bisnis (Dharwiyanti, 2003). Dengan menggunakan UML kita dapat membuat model untuk semua jenis aplikasi perangkat lunak, dimana aplikasi tersebut dapat berjalan pada perangkat keras, sistem operasi dan jaringan apapun, serta ditulis dalam bahasa pemrograman apapun. Selain itu UML juga dapat diartikan sebagai keluarga notasi grafis yang didukung oleh model model tunggal, yang membantu pendeskripsian dan desain sistem perangkat lunak, khususnya sistem yang dibangun menggunakan pemrograman berorientasi objek (Fowler, 2005). Seperti bahasa bahasa lainnya, UML mendefinisikan notasi dan syntax atau semantik. Notasi UML merupakan sekumpulan bentuk khusus untuk menggambarkan berbagai diagran piranti lunak. Setiap bentuk memiliki makna tertentu, dan syntax UML mendifinisikan bagaimana bentuk bentuk tersebut dapat dikombinasikan. UML akan digunakan pada tahap analisa dan desain. Desain yang dihasilkan berupa diagram 33

28 diagram UML yang akan diterjemahkan menjadi kode program pada tahap implementasi. Tabel 2.2. Jenis diagram resmi UML (Munawar, 2005) No Diagram Kegunaan 1 Activity Perilaku procedural pararel 2 Class Class, fitur, dan relasinya 3 Communication Interaksi antar objek; penekanan pada link 4 Component Struktur dan koneksi dari komponen 5 Composite Structure Dekomposisi sebuah class pada saat runtime 6 Deployment Penyebaran / instalasi ke klien 7 Interactive Overview Gabungan sequence dan activity diagram 8 Object Contoh konfigurasi dari contoh contoh 9 Package Struktur hierarki saat kompilasi 10 Sequence Interaksi antar objek; penekanan pada sequence 11 State machine Bagaimana event mengubah objek selama aktif 12 Timing Interaksi antar objek; penekanan pada timing 13 Use Case Bagaimana pengguna berinteraksi dengan sebuah sistem Diagram UML yang akan dibahas pada bab ini adalah use case diagram, activity diagram, sequncei diagram, dan statechart diagram. 34

29 b. Use Case Diagram Use case diagram adalah teknik untuk merekam persyaratan fungsional sebuah sitem. Use case diagram mendeskripsikan interaksi tipikal antara para pengguna system dengan sistem itu sendiri, dengan memberi sebuah narasi tentang bagaimana system tersebut digunakan (Fowler, 2005). Use case menjelaskan manfaat system jika dilihat menurut pandangan orang yang berada di luar system (aktor) diagram ini menunjukan fungsionalitas suatu system atau kelas dan bagaimana sistem berinteraksi dengan dunia luar (Suhendar, 2002). Sebuah use case diagram merepresentasikan sebuah interaksi antara aktor dengan sistem. Use case merupakan sebuah pekerjaan tertentu, misalnya login ke sistem, membuat sebuah daftar belanja, dan sebagainya. Seorang atau sebuah aktor adalah sebuah entitas manusia atau mesin yang berinteraksi dengan sistem untuk melakukan pekerjaan pekerjaan tertentu. Sebuah use case dapat memasukkan fnugsionalitas use case lain sebagai bagian dari proses di dalamnya. Secara umum diasumsikan bahwa use case yang dimasukkan akan dipanggil setiap kali use case yang memasukkan dieksekusi secara normal. Sebuah use case juga dapat memperluas use case lain dengan perilakunya sendiri. Sementara hubungan generalisasi antar use case menunjukkan bahwa use case yang satu merupakan spesialisasi dari yang lain. 35

30 Tabel 2.3. Notasi Use Case Diagram (Booch, 1998) Notasi Deskripsi Aktor, yang digunakan untuk menggambarkan pelaku atau pengguna. Pelaku ini meliputi manusia atau sistem computer atau subsistem lain yang memiliki metode untuk melakukan sesuatu. Contoh: Manager, pelanggan, dan lain lain. Use case, digunakan untuk menggambarkan spesifikasi pekerjaan (job specification) dan deskripsi pekerjaan (job description), serta keterkaitan antar pekerjaan. Contoh: pesan barang, menutup pintu, dan lain lain. Aliran proses (relationship), digunakan untuk menggambarkan hubungan anatar use case dengan use case lainnya. Aliran perpanjangan (extension point), digunakan untuk menggambarkan hubungan antara use case dengan use case yang diperpanjang (extended use case) maupun dengan use case yang dimasukkan (included use case). Aliran yang digunakan untuk menggambarkan hubungan antara aktor dengan use case. Kondisi yang mendeskripsikan apa yang terjadi antara use case <<extended>> dengan use case yang diperpanjang. 36

31 Tabel 2.3. Notasi Use Case Diagram (lanjutan) Notasi Keterangan <<include>> Include adalah kondisi aliran proses langsung (directed relationship) antara dua use case yang secara tak langsung menyatakan kelakuan (behaviour) dari use case yang dimasukkan. <<has>> Adalah kondisi yang mendeskripsikan apa yang terjadi antara aktor dengan use case. c. Sequence Diagram Sebuah sequence diagram secara khusus menjabarkan ektivitas sebuah skenario tunggal. Diagram tersebut menunjukkan sejumlah objek contoh dan pesan pesan yang melewati objek objek di dalam use case diagram (Fowler, 2005). Sequence diagram menunjukkan interaksi dengan menampilkan setiap partisipan dengan garis alir secara vertical dengan pengurutan pesan dari atas ke bawah. Sequence diagram biasa digunakan untuk menggambarkan scenario atau rangkaian langkah langkah yang dilakukan sebagai respon dari sebuah kejadian (event) untuk menghasilkan keluaran tertentu. Masing masing objek, termasuk aktor, memiliki lifeline vertikal. Pesan digambarkan sebagai garis berpanah dari satu objek ke objek lainnya. 37

32 Tabel 2.4. Notasi Sequence Diagram (Fowler, 2005) No Notasi Keterangan 1 Frame, digunakan untuk menggambarkan sebuah interaksi :message Lifeline, digunakan untuk mempresentasikan sebuah individu dalam interaksi dan hanya sebuah entitas interaksi Execution Specification, digunakan untuk menggambarkan spesifikasi dari sebuah unit kelakuan atau aksi antar lifeline. Pesan(message), digunakan untukmendeskripsikan pesan yang ada antar lifeline. Lost message, digunakan untuk menggambarkan sebuah pesan yang 5 mendefinisikan komunikasi particular antara lifelines dalam interaksi lifeline n+1 ke lifeline n. Found message, digunakan untuk menggambarkan sebuah pesan yang 6 mendefinisikan komunikasi particular antara lifelines dalam interaksi lifeline n ke lifeline n+1. Objek, digunakan untuk menggambarkan pelaku atau pengguna dalam 7 sequence diagram. Pelaku ini meliputi manusia atau sistem computer atau subsistem lain yang memiliki metode untuk melakukan sesuatu Aktor, yang digunakan untuk menggambarkan pelaku atau pengguna 8 dalam use case. Pelaku ini meliputi manusia atau sistem komputer atau subsistem lain yang memiliki metode untuk melakukan sesuatu. 38

33 d. Activity Diagram Diagram aktivitas adalah teknik untuk mendeskripsikan logika procedural, proses bisnis dan aliran kerja dalam banyak kasus (Munawar, 2005). Activity diagram memodelkan alur kerja (workflow) sebuah proses bisnis dan urutan aktivitas dalam suatu proses. Diagram ini sangat mirip dengan sebuah flowchart karena kita dapat memodelkan sebuah alur kerja dari suatu aktivitas ke akitivitas lainnya atau dari suatu aktivitas ke dalam keadaan sesaat (state). Seringkali bermanfaat bila kita membuat sebuah activity diagram terlebih dahulu dalam memodelkan sebuah proses untuk membantu kita memahami proses secara keseluruhan. Activity diagram juga sangat berguna ketika kita ingin menggambarkan perilaku pararel/menjelaskan bagaimana perilaku dari berbagai use case berinteraksi. Tabel 2.5. Notasi activity diagram (Fowler, 2005) No Notasi Keterangan Aktivitas, digunakan untuk menggambarkan aktivitas dalam diagram aktivitas Node keputusan (decision node), digunakan untuk mengambarkan kelakuan pada kondisi tertentu. Titik awal, digunakan untuk menggambarkan awal dari diagram aktivitas 39

34 Tabel 2.5. Notasi activity diagram (lanjutan) No Notasi Keterangan 4 5 Titik akhir (final action), digunakan untuk menggambarkan akhir dari diagram aktivitas Akhir alur (flow final), digunakan untuk menghancurkan semua tanda yang datang dan tak memiliki efek alur dalam aktivitas Aksi (action), digunakan untuk menggambarkan alur antara 6 aksi dengan aksi, titik awal dengan aksi, atau aksi dengan titik akhir Aksi penerimaan kejadian (accept event action), sebuah aksi 7 yang menunggu sebuah kejadian dari suatu peristiwa bertemu 8 <<datastore>> dengan kondisi tertentu. Datastore digunakan untuk menjaga agar semua tanda yang masuk dan menduplikasinya saat mereka dipilih untuk pindah ke alur selanjutnya(downstream) 9 Node fork memiliki satu aksi yang masuk dan beberapa aksi yang keluar 10 Join node digunakan untuk menggambarkan beberapa aksi yang masuk dan satu aksi yang keluar. 40

35 e. Statechart Diagram Menurut Booch, Rambaugh, dan Jacobson, statechart diagram menggambarkan kemungkinan status dari sebuah kelas dan kejadian(events) yang mengakibatkan perubahan status (state transition). Pada umumnya statechart diagram menggambarkan class tertentu (satu class dapat memiliki lebih dari satu statechart diagram). Tabel 2.6. Notasi Statechart Diagram (Booch, 1998). No Notasi Keterangan 1 State 1 Notasi state menggambarkan kondisi sebuah entitas, dan digambarkan dengan segiempat yang pinggirnya tumpul dengan nama state di dalamnya Transition, menggambarkan sebuah perubahan kondisi objek yang 2 Transition disebabkan oleh sebuah event. Transition digambarkan dengan sebuah anak panah dengan nama event yang ditulis di atasnya, dibawahnya, atau sepanjang anak panah tersebut Initial state adalah kondisi awal sebuah objek sebelum ada perubahan 3 keadaan. Initial state digambarkan dengan sebuah lingkaran solid. Hanya satu initial state yang diizinkan dalam sebuah diagram Final state, menggambarkan ketika objek berhenti memberi respon 4 terhadap sebuah event. Final state digambarkan dengan lingkaran solid di dalam sebuah lingkaran kosong 41

36 f. Class Diagram Class Diagram adalah sebuah spesifikasi yang jika diinstansiasi akan menghasilkan sebuah obyek dan merupakan inti dari pengembangan dan desain berorientasi obyek. Class menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut (metoda/fungsi). Class diagram menggambarkan struktur dan deskripsi class, package dan object beserta hubungan satu sama lain seperti containment, pewarisan, asosiasi, dan lainlain. Sebuah Class memiliki tiga area pokok : 1. Nama, merupakan nama dari sebuah kelas. 2. Atribut, merupakan peroperti dari sebuah kelas. Atribut melambangkan batas nilai yang mungkin ada pada obyek dari class. 3. Operasi, adalah sesuatu yang bisa dilakukan oleh sebuah class atau yang dapat dilakukan oleh class lain terhadap sebuah class. Atribut dan metoda dapat memiliki salah satu sifat berikut : 1. Private, tidak dapat dipanggil dari luar class yang bersangkutan. 2. Protected, hanya dapat dipanggil oleh class yang bersangkutan dan anak-anak yang mewarisinya. 3. Public, dapat dipanggil oleh siapa saja. 4. Package, hanya dapat dipanggil oleh instance sebuah class pada paket yang sama. Berikut adalah notasi notasi yang ada pada class diagram : 42

37 Tabel 2.7. Notasi Class Diagram (Booch, 1998). No Notasi Keterangan Class adalah blok - blok pembangun pada pemrograman 1 Site Config +sqldns:string +Admin String berorientasi obyek. Sebuah class digambarkan sebagai sebuah kotak yang terbagi atas 3 bagian. Bagian atas adalah bagian nama dari class. Bagian tengah mendefinisikan property/atribut class. Bagian akhir mendefinisikan methodmethod dari sebuah class. Assosiation, sebuah asosiasi merupakan sebuah relationship paling umum antara 2 class, dan dilambangkan oleh sebuah garis yang menghubungkan antara 2 class. Garis ini bisa 2 1..n Owned by 1 melambangkan tipe-tipe relationship dan juga dapat menampilkan hukum-hukum multiplisitas pada sebuah relationship (Contoh: One-to-one, one-to-many, many-tomany). Composition, jika sebuah class tidak bisa berdiri sendiri dan harus merupakan bagian dari class yang lain, maka class 3 tersebut memiliki relasi Composition terhadap class tempat dia bergantung tersebut. Sebuah relationship composition digambarkan sebagai garis dengan ujung berbentuk jajaran genjang berisi/solid. 43

38 Tabel 2.7. Notasi Class Diagram (lanjutan). No Notasi Keterangan Dependency, kadangkala sebuah class menggunakan class yang lain. Hal ini disebut dependency. Umumnya penggunaan 4 dependency digunakan untuk menunjukkan operasi pada suatu class yang menggunakan class yang lain. Sebuah dependency dilambangkan sebagai sebuah panah bertitik-titik. Aggregation, mengindikasikan keseluruhan bagian relationship dan biasanya disebut sebagai relasi mempunyai 5 sebuah atau bagian dari. Sebuah aggregation digambarkan sebagai sebuah garis dengan sebuah jajaran genjang yang tidak berisi/tidak solid. Generalization, sebuah relasi generalization sepadan dengan sebuah relasi inheritance pada konsep berorientasi obyek. 6 Sebuah generalization dilambangkan dengan sebuah panah dengan kepala panah yang tidak solid yang mengarah ke kelas parent -nya/induknya. 44