BAB I

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
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
Jakarta, 20 mei 2000
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
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
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 1 + 3 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
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
R/
R/
: xx
: Nama Dokter
: xx/xx/xxxx
: Nama pasien
Amoxycillin 500
S.3.d.d.I
Ponstan FCT
S.p.r.n.I
No XII
-------det
No XII
-------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
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
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
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
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
bahan pertimbangan, seperti ruang lingkup penggunaan, serta ukuran yang
dibutuhkan.
Tabel 2.1 Error Correction Level Pada QRCode (Anonymus, 2009)
Tingkat Kerusakan
Tingkatan / Level
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.
2.3. 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
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
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
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
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
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
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
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
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
(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
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
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
B
A merupakan determinant 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
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
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
dependency.
Join
dependency
menggambarkan
sebuah
tipe
ketergantungan yang, jika dan hanya jika, nilai legal sebuah relasi sama
dengan proyeksi gabungan atribut – atributnya.
2.4. 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
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
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 2.10. 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
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
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
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
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
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
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.
Adalah kondisi yang mendeskripsikan apa yang terjadi antara aktor
<<has>>
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
Tabel 2.4. Notasi Sequence Diagram (Fowler, 2005)
No
Notasi
1
Keterangan
Frame, digunakan untuk menggambarkan sebuah interaksi
Lifeline, digunakan untuk mempresentasikan sebuah individu dalam
2
interaksi dan hanya sebuah entitas interaksi
Execution Specification, digunakan untuk menggambarkan spesifikasi
3
dari sebuah unit kelakuan atau aksi antar lifeline.
Pesan(message), digunakan untukmendeskripsikan pesan yang ada
4
1:message
antar lifeline.
Lost message, digunakan untuk menggambarkan sebuah pesan yang
5
mendefinisikan komunikasi particular antara lifelines dalam interaksi
lifelinen+1 ke lifelinen.
Found message, digunakan untuk menggambarkan sebuah pesan yang
6
mendefinisikan komunikasi particular antara lifelines dalam interaksi
lifelinen ke lifelinen+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
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
1
diagram aktivitas
Node keputusan (decision node), digunakan untuk mengambarkan
2
kelakuan pada kondisi tertentu.
Titik awal, digunakan untuk menggambarkan awal dari diagram
3
aktivitas
39
Tabel 2.5. Notasi activity diagram (lanjutan)
No
Notasi
Keterangan
Titik akhir (final action), digunakan untuk menggambarkan
4
akhir dari diagram aktivitas
Akhir alur (flow final), digunakan untuk menghancurkan semua
5
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
dengan kondisi tertentu.
Datastore digunakan untuk menjaga agar semua tanda yang
8
<<datastore>>
masuk dan menduplikasinya saat mereka dipilih untuk pindah
ke alur selanjutnya(downstream)
Node fork memiliki satu aksi yang masuk dan beberapa aksi
9
yang keluar
Join node digunakan untuk menggambarkan beberapa aksi
10
yang masuk dan satu aksi yang keluar.
40
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
Notasi state menggambarkan kondisi sebuah entitas, dan digambarkan
1
State 1
dengan segiempat yang pinggirnya tumpul dengan nama state di dalamnya
Transition, menggambarkan sebuah perubahan kondisi objek yang
disebabkan oleh sebuah event. Transition digambarkan dengan sebuah anak
2
Transition
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
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
Tabel 2.7. Notasi Class Diagram (Booch, 1998).
No
Notasi
Keterangan
Class adalah blok - blok pembangun pada pemrograman
berorientasi obyek. Sebuah class digambarkan sebagai sebuah
Site Config
kotak yang terbagi atas 3 bagian. Bagian atas adalah bagian
1
+sqlDNS:string
+Adminemail:String
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
menampilkan hukum-hukum multiplisitas pada
dapat
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
tersebut memiliki relasi Composition terhadap class tempat
3
dia bergantung tersebut. Sebuah relationship composition
digambarkan sebagai garis dengan ujung berbentuk jajaran
genjang berisi/solid.
43
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.
Sebuah generalization dilambangkan dengan sebuah panah
6
dengan kepala panah yang tidak solid yang mengarah ke
kelas
“parent”-nya/induknya.
44