BAB 2 LANDASAN TEORI 2.1 E-Commerce 2.1.1 Pengertian E

9
BAB 2
LANDASAN TEORI
2.1 E-Commerce
2.1.1 Pengertian E-Commerce
Menurut David Baum, pengertian e-commerce adalah: “ECommerce is
a dynamic set of technologies, applications, and business process that link
enterprise, consumers, and communities through electronic transactions and
the electronic exchange of goods, services, and information” ,( Baum dalam
Purbo, 2000 : 2).
Dalam teori David Baum, disampaikan bahwa bukan hanya proses
transaksi dan proses servis melalui teknologi elektronik yang menjadi bagian
dari e-commerce, akan tetapi proses penyampaian informasi melalui
teknologi elektronik juga merupakan bagian dari e-commerce.
Electronic Commerce (EC) adalah suatu konsep yang menjelaskan
proses pembelian, penjualan dan pertukaran produk, servis dan informasi
melalui jaringan komputer yaitu internet (Turban, 2010). Menurut Kalakota
(1999) EC dapat dilihat dari sudut pandang :
•
Sudut pandang komunikasi, EC merupakan pengiriman barang, servis,
informasi, atau pembayaran melalui jaringan komputer.
•
Sudut pandang bisnis proses, EC adalah aplikasi teknologi yang dapat
melakukan transaksi bisnis dan arus kerja yang otomatis.
•
Sudut pandang servis, EC merupakan peralatan yang dapat memenuhi
keinginan perusahaan, konsumen dan managemen untuk memotong
10
biaya servis selama pengembangan kualitas barang dan peningkatan
kecepatan layanan pengiriman.
•
Sudut pandang online, EC menyediakan kemampuan untuk membeli dan
menjual produk dan informasi melalui internet dan layanan online
lainnya.
Secara umum ada tiga tipe EC yaitu:
•
B2C (Business to Customer), dalam B2C transaksi online dibuat antara
bisnis dengan konsumen secara individual. Contoh : pesanan buku secara
online, pembelian tiket pesawat terbang.
•
B2B (Business to Business), dalam B2B bisnis membuat transaksi online
dengan bisnis lain. Contoh : Layanan online atau pembelian bahan bakar.
•
B2E (Business to Employee), dalam B2E informasi dan servis dibuat
secara online untuk para pekerja. Contoh : Pelatihan online dan
perbankan online.
EC dapat dibedakan menjadi dua bagian yaitu pure EC dan partikel EC.
Pure EC menerangkan semua bagian dalam EC menggunakan dimensi digital
baik dalam produk, proses dan pengiriman. Pure EC sulit untuk dilakukan
karena apabila produk dalam bentuk hard goods maka pengiriman tidak dapat
dilakukan melalui dimensi digital. Sedangkan yang kedua adalah partial EC,
menjelaskan
bahwa
EC
menggunakan
semua
kemungkinan
untuk
menggabungkan dimensi digital dan physical. Dalam penelitian ini akan
digunakan metode partial EC, dimana produk yang dijual berupa produk hard
goods sehingga pengiriman dilakukan melalui jasa pengiriman sedangkan
pembayaran dilakukan secara digital melalui kartu kredit, yang ditunjukkan
melalui simulasi sederhana.
11
2.1.1 Keuntungan E-commerce
Menurut Purbo dan Wahyudi (2001, p5), keuntungan yang dapat
diperoleh dengan adanya e-commerce adalah:
•
Revenue stream (aliran pendapatan) baru yang mungkin lebih
menjajikan, yang tidak dapat ditemui di sistem transaksi tradisional.
•
Dapat meningkatkan market exposure (pangsa pasar).
•
Menurunkan biaya operasional (operating cost).
•
Memperluas jangkauan (global reach).
•
Meningkatkan customer loyalty.
•
Meningkatkan supplier management.
•
Mempersingkat waktu produksi.
•
Meningkatkan value chain (mata rantai pendapatan).
2.2 HTML
Menurut Diar Puji Oktavian (2010, p13), HTML(Hyper Text Markup
Language) adalah suatu bahasa yang dikenali oleh web browser untuk menampilkan
informasi dengan lebih menarik dibandingkan dengan tulisan text biasa (plain text).
Sedangkan web browser adalah program komputer yang dikunakan untuk membaca
HTML, kemudian menerjemahkan dan menampilkan hasilnya secara bisul ke layar
komputer.
2.3 Website
Website atau situs juga dapat diartikan sebagai kumpulan halaman – halaman
yang menampilkan informasi data teks, data gambar diam atau gerak, data animasi,
suara, video dan atau gabungan dari semuanya, baik yang bersifat statis maupun
dinamis yang membentuk satu rangkaian bangunan yang saling terkait dimana
masing-masing dihubungkan dengan jaringan-jaringan halaman (hyperlink).
12
Bersifat statis apabila isi informasi website tetap, jarang berubah, dan isi
informasinya searah hanya dari pemilik website. Bersifat dinamis apabila isi
informasi website selalu berubah-ubah, dan isi informasinya interaktif dua arah
berasal dari pemilik serta pengguna website.
Untuk menyediakan sebuah website, maka unsur-unsur penunjangnya antara
lain:
•
Nama Domain (URL)
•
Hosting dapat diartikan sebagai ruangan yang terdapat dalam harddisk tempat
menyimpan berbagai data, file-file, gambar dan lain sebagainya yang akan
ditampilkan di situs.
•
Scripts/Bahasa Program adalah bahasa yang digunakan untuk menerjemahkan
setiap perintah dalam situs pada saat diakses. Jenis scripts sangat menentukan
statis, dinamis, interaktifnya, atau bisa dibilang performa sebuah situs. Jenisjenis scripts yang banyak dipakai para designer antara lain HTML, ASP,
PHP, JSP, Java Scripts, Java Applets dan sebagainya.
2.4 Web Database
Menurut Barry Eaglestone dan Mick Ridley (Web Database System, 2001),
sistem database dapat dihubungkan ke internet untuk digunakan melalui web.
Berikut ini adalah tipe-tipe dari koneksi yang dapat digunakan:
•
Remote Connection : Sebuah sistem database, dimana dapat di akses melalui
web dimanapun user berada.
•
Client-Server Architectures : Ini adalah bentuk umum untuk program aplikasi
database menggunakan internet.
•
Distributed Database : Beberapa DBMS mempunyai fasilitas untuk
mengijinkan bagian tertentu dari database disimpan pada komputer yang
13
berbeda-beda. Data tersebut didistribusikan diletakkan di tempat-tempat
berbeda, dan hal ini tidak disadari oleh user.
2.5 Hypertext Preprocessor (PHP)
PHP (Hyertext Preprocessor) adalah bahasa server-side scripting yang
digunakan untuk aplikasi web yang dinamis dan interaktif. Hal ini berarti bahwa PHP
bekerja dalam dokumen HTML, untuk membuat dokumen HTML tersebut bisa
menghasilkan isi yang diminta. Anda dapat mengubah halaman website anda menjadi
sebuah aplikasi web, tidak hanya berupa halaman-halaman statis dengan informasi
yang tidak sering diperbaharui dimana mungkin untuk ”personal” website masih
mungkin digunakan, tetapi tidak untuk penggunaan dalam lingkungan bisnis ataupun
pendidikan.
Cara kerja halaman yang menggunakan PHP : (Castagnetto,2000,p60) Ketika
sebuah permintaan/request untuk sebuah halaman web dari browser, maka web
server akan melakukan langkah-langkah sebagai berikut :
•
Membaca permintaan/request dari browser
•
Mencari halaman pada server
•
Melakukan
instruksi-instruksi
yang
disediakan
dalam
PHP
untuk
memodifikasi halaman web
•
Mengirimkan kembali halaman web ke browser melalui internet atau intranet
Bahasa pemrograman PHP memiliki beberapa kelebihan dibandingkan dengan
bahasa pemrograman lainnya, antara lain:
•
Kecepatan akses yang tinggi (karena code di embedded di dalam web server).
•
Dapat bekerja dalam berbagai webserver (Apache, IIS, Microsoft Personal
WebServer) dan sistem operasi yang berbeda pula.
•
PHP merupakan freeware/opensource
14
•
Karena dijalankan pada webserver, maka secara otomatis program yang
dihasilkan bersifat multiuser
2.6 SQL
Mengacu pada pendapat Connolly dan Begg (2002) SQL dikemukakan sebagai
suatu bahasa yang dipergunakan untuk mengakses data dalam database relational.
Bahasa ini secara de facto merupakan bahasa standar yang digunakan dalam
manajemen database relational. Saat ini hampir semua server database yang
mendukung bahasa ini untuk melakukan manajemen terhadap datanya.
• Standarisasi
Standarisasi SQL dimulai pada tahun 1986, ditandai dengan
dikeluarkannya standar SQL oleh ANSI. Standar ini sering disebut dengan
SQL86. Standar tersebut kemudian diperbaiki pada tahun 1989 kemudian
diperbaiki lagi pada tahun 1992. Versi terakhir dikenal dengan SQL92.
Pada tahun 1999 dikeluarkan standar baru yaitu SQL99 atau disebut
juga SQL99, akan tetapi kebanyakan implementasi mereferensi pada
SQL92. Saat ini sebenarnya tidak ada server database yang 100 persen
mendukung SQL92. Hal ini disebabkan masing-masing server memiliki
kebudayaan masing-masing.
• Pemakaian dasar
Secara umum, SQL terdiri dari dua bahasa, yaitu Data Definition
Language (DDL) dan Data Manipulation Language (DML). Implementasi
DDL dan DML berbeda untuk tiap DBMS, namun secara umum
implementasi tiap bahasa ini memiliki bentuk standar yang ditetapkan
ANSI. Pada bagian ini akan dibahas penggunakan bentuk paling umum
yang dapat digunakan pada kebanyakan DBMS.
15
• Data Definition Language (DDL)
DDL digunakan untuk mendefinisikan, mengubah, serta menghapus
database dan objek-objek yang diperlukan dalam database, misalnya Table,
View, User, dan sebagainya. Secara umum, DDL yang digunakan adalah
CREATE untuk membuat objek baru, USE untuk menggunakan objek,
ALTER untuk mengubah objek yang sudah ada,dan DROP untuk
menghapus objek. DDL biasanya digunakan oleh administrator database
dalam pembuatan sebuah aplikasi database.
Contoh : CREATE DATABASE Product, USE Product, ALTER Table
MsUser ADD PhoneNumber null, DROP Table MsUser
• Data Manipulation Language (DML)
DML digunakan untuk memanipulasi data yang ada dalam suatu
tabel. Perintah yang umum dilakukan adalah :
a. SELECT
Perintah yang paling sering digunakan pada SQL, sehingga
kadang kadang istilah Query dirujukkan pada perintah
SELECT. SELECT digunakan untuk menampilkan data dari
satu atau lebih tabel, biasanya dalam sebuah database yang
sama.
Contoh : Select * From MsUser
b. INSERT
Untuk menambah data dalam tabel
Contoh : Insert into MsUser
values(‘MS00000001’,’Anthoni’,12345)
c. UPDATE
16
Untuk mengubah data
Contoh : Update Personal_info Set salary = salary * 1.03
d. DELETE
Untuk menghapus data
Contoh : Delete from MsUser where UserId=’MS00000001’
2.7 Teori Basis Data
2.7.1 Pengertian Data
Mengacu pada pendapat Connoly dan Begg (2010) Data
dikemukakan sebagai suatu deskripsi dari sesuatu dan kejadian yang
dihadapi dan jembatan antara komponen mesin dan komponen manusia.
2.7.2 Pengertian Database
Mengacu pada pendapat Connolly dan Begg (2010) database
dikemukakan sebagai sekumpulan informasi yang saling berkaitan pada
suatu subjek tertentu pada tujuan tertentu pula atau susunan record
operational data lengkap dari suatu organisasi atau perusahaan, yang
diorganisir dan disimpan secara reintegrasi dengan menggunakan metode
tertentu dalam komputer sehingga mampu memenuhi informasi yang
optimal yang dibutuhkan oleh para pengguna.
Database merupakan bagian sangat penting dalam sebuah proses
pengolahan data. Data tersebut harus dapat diakses dengan urutan yang
berbeda-beda secara logis dengan cara yang relatif mudah.
2.7.3 Arsitektur Basis Data
Menurut Thomas M. Connolly dan Carolyn Begg (2010, p86), ada
tiga level arsitektur basis data (Three-Level ANSI-SPARC Architecture)
yaitu:
17
External Level
Level ini merupakan view basis data pada user. Setiap user
mempunyai
view
masing-masing
tergantung
kebutuhan
informasi dari user tersebut.
Conceptual Level
Level ini menggambarkan data apa saja yang disimpan dalam
basis data dan hubungan antara data-data tersebut.
Internal Level
Level ini merupakan reperesentasi fisik dari basis data yang
ada di komputer. Level ini menggambarkan bagaimana data
disimpan dalam suatu basis data.
2.7.4 Sistem Basis Data
Sistem basis data merupakan kumpulan dari program aplikasi yang
berinteraksi dengan basis data (Connolly dan Begg, 2010, 54).
Jadi, sistem basis data ialah kombinasi dari beberapa program
aplikasi dengan basis data yang telah berjalan sehingga keseluruhan
sistem terkomputerisasi tersebut memungkinkan pengguna menelusuri
kembali dan mengubah informasi sesuai kebutuhan.
2.7.5 Database Ralational
Database Relational merupakan database yang dalam gambaran
penggunaannya
merupakan kumpulan dari tabel-tabel, dimana tabel
tersebut terdiri dari baris dan kolom, atau dengan kata lain terdiri dari
kumpulan record dan field. Tabel tersebut kemudian dihubungkan dengan
satu field di tabel lain yang disebut sebagai key.
18
Pada database relational terdapat dua jenis field yang dapat
menggambarkan hubungan, yaitu primary key dan foreign key. Primary
Key adalah suatu field yang menghubungkan satu tabel dengan tabel
lainnya. Foreign key merupakan sebuah field yang digunakan sebagai
field tujuan yang dihubungkan dengan field dari tabel pemanggil.
Hubungan antar tabel dalam database relational dapat dibagi menjadi
tiga, yaitu:
•
Hubungan one to one, ialah hubungan antar tabel dimana satu isi
record pada satu tabel hanya dapat berhubungan dengan satu
record pada tabel lainnya.
•
Hubungan one to many atau many to one, ialah hubungan antar
tabel dimana satu isi record pada satu tabel dapat berhubungan
dengan beberapa record pada tabel lainnya atau sebaliknya.
•
Hubungan many to many, ialah hubungan antar tabel dimana satu
isi record pada tabel X dapat berhubungan dengan beberapa
record pada tabel X.
2.7.6 Database Management System (DBMS)
2.7.6.1 Pengertian Database Management System (DBMS)
Menurut Thomas M. Connolly dan Carolyn Begg (2010,
p66), DBMS adalah suatu sistem software yang memungkinkan
user untuk mendefinisikan, menciptakan, memelihara dan
mengontrol pengaksesan terhadap suatu basis data.
2.7.6.2 Keuntungan dan Kerugian DBMS
Keuntungan DBMS menurut Connolly (2010, p77) adalah
sebagai berikut :
19
1. Mengontrol redundansi data
2. Data yang konsisten
3. Banyak informasi dari sejumlah data yang sama
4. Membagi (sharing) data
5. Meningkatkan integritas data
6. Meningkatkan keamanan
7. Standarisasi
Kerugian DBMS menurut Connolly (2010, p80) adalah
sebagai berikut :
1. Kompleksitas
2. Ukuran
3. Biaya DBMS
4. Penambahan biaya piranti keras
5. Performa
6. Resiko kesalahan yang tinggi
2.7.6.3 Fungsi DBMS
Fungsi DBMS dapat dilihat sebagai berikut :
1. Penyimpanan, pengembalian dan peng-updatean data
2. Memperbolehkan user untuk mengakses
3. Pendukung transaksi
4. Layanan pengontrolan data yang sama
5. Layanan perbaikan
6. Layanan hak akses
7. Pendukung untuk komunikasi data
8. Layanan integritas data
20
9. Layanan untuk meningkatkan data yang tetap
(independence)
10. Layanan utilitas (kegunaan)
2.7.7 Database Language
Setiap pengguna basis data memerlukan bahasa pemrograman yang
dapat dipakai sesuai dengan fungsi dan tugasnya. Dalam basis data,
secara umum dikenal dua bahasa, yaitu:
1. Data Definition Language (DDL) : bahasa yang dipakai untuk
menjelaskan objek dari bahasa data. DDL memungkinkan
pengguna untuk menspesifikasikan tipe dan struktur data serta
batasan pada data yang tersimpan pada basis data.
2. Data Manipulation Language (DML) : bahasa yang dipakai untuk
memanipulasi objek data dari basis data. DML dipakai untuk
operasi terhadap isi basis data (insert, update, delete, select).
2.7.8 Normalisasi
2.7.8.1 Pengertian Normalisasi
Menurut Connolly(2010, p415), normalisasi adalah suatu
teknik yang menghasilkan himpunan relasi dengan properti yang
diinginkan berdasarkan kebutuhan data dari sebuah perusahaan.
2.7.8.2 Tahap-tahap Normalisasi
1. Unnormalized Form (UNF)
Menurut Connolly(2010, p430), UNF adalah suatu tabel
yang berisikan satu atau lebih kumpulan data yang berulang
(repeating group). Repeating group ialah sebuah/himpunan
21
atribut di dalam tabel yang memiliki lebih dari satu nilai
(multiple value) untuk sebuah primary key pada tabel tersebut.
2. First Normal Form (1NF)
Menurut Connolly(2010, p430), suatu relasi dikatakan
1NF jika titik temu tiap baris dan kolom pada relasi tersebut
mengandung satu dan hanya satu nilai. Sebuah relasi akan
berada dalam bentuk 1NF jika repeating groupnya sudah
hilang
3. Second Normal Form (2NF)
Menurut Connolly(2010, p434), suatu relasi dikatakan
2NF jika relasi tersebut berada pada 1NF dan setiap atribut
yang bukan primary key bergantung sepenuhnya terhadap
primary key.
4. Third Normal Form (3NF)
Menurut Connolly(2010, p436), suatu relasi dikatakan
3NF jika relasi tersebut berada dalam bentuk 1NF dan 2NF,
dan tidak ada atribut yang bukan primary key bergantung
secara transitif terhadap primary key.
2.7.9 Entity RelationshipModelling
2.7.9.1 Entity Types
Menurut Connolly(2010, p372), tipe entitas adalah
sekumpulan objek dengan properti yang sama yang diidentifikasi
Entitas
oleh perusahaan. Representasi Diagramatik dari Entitas Nama
:
22
2.7.9.2 Relationship Types
Menurut Connolly(2010, p334), tipe relasi adalah
sekumpulan entitas yang memiliki relasi satu sama lain.
Relationship Occurence adalah suatu gabungan yang
dapat diidentifikasikan secara unik, yang meliputi satu kejadian
dari setiap tipe entitas yang berpartisipasi.
2.7.9.3 Atribut
Menurut Connolly (2010, p338), Atribut ialah sebuah
properti dari sebuah entitas atau tipe relasi. Atribut terdiri dari :
1. Simple and Composite Attributes
Simple attributes adalah atribut yang terdiri dari komponen
tunggal dengan keberadaan independent (tetap). Atribut
simple kadang disebut juga komponen atomik (tidak bisa
dibagi).
Composite attributes adalah atribut yang terdiri dari
banyak komponen dengan keberadaan independent (tetap).
2. Single-Valued and Multi-Valued Attributes
Single-Valued attributes adalah atribut yang memiliki nilai
tunggal untuk masing – masing kejadian dari sebuah
entitas.
Multivalued attributes adalah atribut yang memiliki
banyak nilai untuk masing – masing kejadian dari sebuah
entitas.
23
3. Derived Attributes
Derived attribute adalah atribut yang menggantikan
sebuah nilai yang diturunkan dari nilai atribut yang
berhubungan atau kumpulan dari atribut, tidak perlu pada
jenis entitas yang sama.
2.7.10 Database System Development Life Cycle (DSDLC)
Database System Development Life Cycle (DSDLC) adalah
tahapantahapan terstruktur yang harus dilakukan untuk merancang
aplikasi sistem basis data. Tahapan pada DSDLC tidak harus berurutan,
tapi dapat melibatkan beberapa pengulangan ke tahapan sebelumnya
melalui feedback loops.
Tahapan-tahapan pada DSDLC tersaji pada gambar 2.1 berikut:
Gambar 2.1 Database System Development Life Cycle
24
1. Database Planning
Tujuan dari database planning (Connolly dan Begg 2010, p313)
adalah merencanakan agar tahap-tahap dari aplikasi basis data dapat
direalisasikan dengan seefektif dan seefisien mungkin.
2. System Definition
Tujuan dari system definition (Connolly dan Begg 2010, p316)
adalah menggambarkan ruang lingkup dari sistem basis data termasuk
user view yang utama.
3. Requirement Collection and Analysis
Requirement Collection and Analysis (Connolly dan Begg 2010,
p316) adalah proses pengumpulan kebutuhan dan analisis informasi
tentang suatu perusahaan dan menggunakan informasi ini untuk
mengidentifikasikan kebutuhan-kebutuhan untuk sistem yang baru.
4. Database Design
Database design (Connolly dan Begg 2010, p320) adalah suatu
proses menciptakan perancangan untuk basis data yang mencakup
keseluruhan operasi dan tujuan-tujuan perusahaan. Dalam database
desing terdapat tiga fase utama, yaitu perancangan koseptual,
perancangan logika dan perancangan fisikal.
5. DBMS Selection
Tujuan dari DBMS selection (Connolly dan Begg 2010, p325)
adalah untuk memilih DBMS yang tepat untuk mendukung sistem basis
data. Tahapan-tahapannya antara lain:
1. Mendefinisikan syarat-syarat sebagai referensi
2. Daftar singkat dua atau tiga produk
25
3. Evaluasi produk
4. Merekomendasikan pilihan dan memproduksi laporan
6. Application Design
Tujuan application design (Connolly dan Begg 2010, p329) ialah
merancang antarmuka pengguna dan program aplikasi yang digunakan
dalam memproses basis data. Dua aspek dalam merancang aplikasi
yaitu:
1. Perancangan transaksi
Transaksi (Connolly dan Begg 2010, p288) ialah
rangkaian aksi yang dilakukan oleh seorang pengguna yang
mengakses atau mengubah isi dari basis data tersebut. Ada tiga
jenis transaksi yaitu:
• Retrieval transaction
Digunakan
untuk
mendapatkan
data
yang
ditampilkan pada layar atau pada pembuatan laporan
• Update transaction
Digunakan
untuk
memasukkan
data
baru,
menghapus data lama atau memodifikasi data yang ada
pada basis data.
• Mixed transaction
Mencakup pengambilan dan pengubahan data.
2. Perancangan antarmuka pengguna
Elemen-elemen dalam merancang suatu antarmuka
pengguna (Connolly dan Begg 2010, p289) antara lain:
• Penetapan judul yang bermakna
26
• Instruksi-instruksi yang dapat dipahami
• Bentuk form yang menarik secara visual
• Penggunaan istilah atau singkatan yang konsisten
• Pemberian tanda penyelesaian
7. Prototyping (optional)
Prototyping (Connolly dan Begg 2010, p333) merupakan proses
membangun sebuah model kerja dari aplikasi basis data. Tujuan
utamanya
ialah
untuk
memungkinkan
pengguna
menggunakan
prototype untuk mengidentifikasi fitur-fitur yang bekerja dengan baik
pada sistem serta kekurangannya, dan memberikan saran bagi
peningkatan kerja sistem atau bahkan memberi masukan terhadap
pengembangan/fitur-fitur baru ke dalam sistem basis data.
8. Implementation
Implementation (Connolly dan Begg 2010, p333) merupakan
realisasi fisikal dari desain basis data dan desain aplikasi.
9. Data Conversion and Loading
Data Conversion and Loading (Connolly dan Begg 2010, p334)
adalah suatu proses mengirim data yang ada ke dalam basis data baru
dan mengubah aplikasi yang ada untuk dijalankan pada basis data baru.
10. Testing
Testing (Connolly dan Begg 2010, p334) merupakan suatu proses
mengeksekusi sistem basis data dengan tujuan untuk menemukan
kesalahan.
27
11. Operational Maintainance
Operational Maintainance (Connolly dan Begg 2010, p335)
merupakan suatu proses memonitor dan memelihara sistem yang diikuti
dengan instalasi.
2.7.11 Perancangan Basis Data
Menurut Thomas M. Connolly dan Carolyn Begg (2010, p467),
tahap utama dari siklus hidup aplikasi basis data ialah perancangan
basis data. Tahap ini dimulai setelah analisis secara menyeluruh dari
kebutuhan
perusahaan
yang
dikerjakan.
Tahap-tahap
dalam
perancangan basis data yaitu:
2.7.11.1 Perancangan Basis Data Konseptual
Menurut Thomas M. Connolly dan Carolyn Begg (2010,
p467), perancangan basis data konseptual adalah proses dari
konstruksi sebuah model informasi yang digunakan dalam
sebuah perusahaan, bebas dari pertimbangan semua fisikal.
Langkah 1 Membangun Model Data Konseptual Lokal untuk
Setiap View
Bertujuan
untuk
membangun
model
data
konseptual dari sebuah perusahaan untuk setiap
view yang spesifik.
Langkah 1.1 Mengidentifikasi tipe entitas
Langkah pertama dalam membangun model data
konseptual adalah dengan mendefinisikan objek –
objek utama user. Objek-objek ini merupakan
tipe – tipe entitas untuk model tersebut. Salah
28
satu metode mengidentifikasikan entitas adalah
dengan memeriksa spesifikasi kebutuhan user
dengan mengidentifikasikan kata benda. Setelah
tipe – tipe entitas tersebut diidentifikasikan,
pemberian nama untuk tiap – tiap entitas haruslah
jelas bagi user. Nama dan deskripsi entitas
sebaiknya disimpan pada kamus data. Jika sebuah
entitas dikenal dengan nama lain yang disebut
dengan sinonim atau alias, maka disimpan juga
pada kamus data.
Langkah 1.2 Mengidentifikasi tipe relasi
Untuk mengidentifikasikan tipe relasi dapat
dilakukan
dengan mencari kata kerja pada spesifikasi
kebutuhan user. Pada umumnya relasi bersifat
biner, yaitu relasi tersebut berada hanya diantara
dua tipe entitas. Namun perlu juga diperhatikan
adanya relasi kompleks yang melibatkan lebih
dari dua tipe entitas dan relasi rekursif yang
melibatkan hanya satu tipe entitas. Setelah
mengidentifikasikan relasi, langkah selanjutnya
adalah menentukan multiplicity setiap relasi.
Batasan multiplicity digunakan untuk memeriksa
dan memelihara kualitas data. Deskripsi relasi
29
dan batasan – batasan multiplicity harus disimpan
dalam kamus data.
Langkah 1.3 Mengidentifikasi dan mengasosiasikan atribut
dengan tipe entitas dan relasi
Pada langkah ini dilakukan identifikasi tipe-tipe
dari fakta mengenai entitas dan relasi yang telah
dipilih
untuk mewakili basis data. Untuk
melakukan langkah ini biasanya dicari kata benda
atau frase kata benda dari spesifikasi kebutuhan
user.
Langkah 1.4 Menentukan domain atribut
Bertujuan untuk menentukan batasan atribut di
model data konseptual lokal. Domain adalah
kumpulan nilai – nilai yang diizinkan untuk satu
atau lebih atribut. Contoh domain untuk atribut
“Jenis Kelamin” pada tabel “staff” adalah sebuah
karakter tunggal yang bernilai hanya “L” (untuk
laki – laki) atau “P” (untuk perempuan). Sebuah
model data yang baik menspesifikasikan domain
untuk setiap atribut dan meliputi:
1. Kumpulan nilai – nilai yang diizinkan untuk
atribut
2. Ukuran dan format atribut
30
Setelah domain atribut diidentifikasikan, nama–
nama domain dan karakteristiknya disimpan pada
kamus data.
Langkah 1.5 Menentukan atribut candidate key dan primary
key
Candidate key adalah kunci yang unik atau tidak
mungkin kembar atau berbeda dengan yang lain,
dapat dipakai untuk mengidentifikasikan satu
baris dalam tipe entitas. Composite key adalah
candidate key yang terdiri dari dua atau lebih
atribut. Primary key adalah candidate key yang
dipilih
sebagai
kunci
primer
untuk
mengidentifikasikan setiap entitas. Alternate key
adalah candidate key yang tidak terpilih menjadi
primary key. Foreign key adalah sebuah atribut
atau kumpulan atribut dalam satu relasi yang
sama dengan candidate key dari beberapa relasi
(mungkin relasi yang sama).
Langkah 1.6 Mempertimbangkan menggunakan konsep
enchanced
modeling (langkah optional)
Bertujuan untuk mempertimbangkan konsep
enhanced modeling seperti spesialisasi atau
generalisasi, agregasi dan komposisi. Pada tahap
ini
jika
memilih
pendekatan
spesialisasi,
31
diusahakan untuk memperhatikan perbedaan
antara entitas dengan mendefinisikan satu atau
lebih subclass dari sebuah entitas superclass. Jika
menggunakan
pendekatan
generalisasi,
diusahakan untuk mengidentifikasikan fitur –
fitur umum antar entitas untuk mendefinisikan
sebuah
entitas
Pendekatan
superclass
agregasi
generalisasi.
digunakan
untuk
merepresentasikan hubungan “mempunyai suatu”
atau “bagian dari” antara tipe – tipe entitas,
dimana
yang
”keseluruhan”
“bagiannya”.
satu
dan
merepresentasikan
yang
Komposisi
lainnya
digunakan
sebagai
untuk
merepresentasikan sebuah asosiasi antara tipe –
tipe entitas yang terdapat kepemilikan yang kuat
dan keterhubungan antara “keseluruhan” dan
“bagiannya”.
Langkah 1.7 Memeriksa model data berulang (redundancy)
Bertujuan untuk memeriksa adanya redundansi
pada model data. Ada 3 aktivitas pada tahap ini,
yaitu:
1. Memeriksa kembali relasi one- to-one (1 : 1)
Pada saat mengidentifikasi entitas, mungkin
akan
teridentifikasi
dua
entitas
yang
merepresentasikan objek yang sama pada
32
perusahaan. Untuk kejadian ini, kedua entitas
tersebut harus digabungkan. Jika primary Key
berbeda, pilih salah satu primary key tersebut
dan biarkan yang lain sebagai alternate key.
2. Menghilangkan relasi yang redundansi
Suatu relasi dikatakan redundan jika informasi
yang sama dapat diperbolehkan melalui relasi
yang lain. Model data yang baik seminimal
mungkin tidak memiliki relasi yang redundan.
3. Mempertimbangkan dimensi waktu
Dimensi waktu dari relasi sangat penting
ketika menilai redundansi.
Langkah 1.8 Validasi model konseptual lokal dengan transaksi
pengguna
Bertujuan untuk memastikan bahwa model
konseptual mendukung kebutuhan transaksi yang
diperlukan bagi view. Dua pendekatan yang
mungkin dilakukan untuk memastikan bahwa
model
data
konseptual
lokal
mendukung
transaksi yang dibutuhkan adalah:
1. Mendeskripsikan transaksi
Memeriksa apakah semua informasi (entitas,
relasi, dan atributnya) yang dibutuhkan oleh
setiap transaksi telah disediakan oleh model,
33
dengan mendokumentasikan sebuah deskripsi
dari kebutuhan transaksi.
2. Memakai jalur transaksi
Memvalidasi model data terhadap transaksi
yang dibutuhkan yang melibatkan diagram
yang merepresentasikan jalur setiap transaksi
dalam Entity Relationship Diagram.
Langkah 1.9 Meninjau kembali model data konseptual dengan
pengguna
Pada langkah ini model data konseptual lokal
ditinjau ulang oleh user. Model data konseptual
meliputi
Entity
Relationship
Diagram
dan
dokumentasi pendukung yang menggambarkan
model data tersebut. Jika terjadi anomali pada
model data, maka harus dilakukan perubahan
yang mungkin memerlukan pengulangan langkah
– langkah sebelumnya. Proses ini terus diulang
sampai model data tersebut benar – benar
menjadi representasi aktual dari perusahaan.
2.7.11.2 Perancangan Basis Data Logikal
Menurut Thomas M. Connolly dan Carolyn Begg (2010,
p467, perancangan basis data logikal adalah suatu proses
membangun sebuah model informasi yang digunakan dalam
sebuah perusahaan berdasarkan sebuah model data spesifik
tetapi bebas dari DBMS dan pertimbangan fisikal lainnya.
34
Langkah 2 Membangun dan Melakukan Validasi Model Data
Logikal Lokal untuk Setiap View
Bertujuan untuk membangun model data logikal
dari
model
data
konseptual
lokal
yang
merepresentasikan view tertentu dari perusahaan
dan
memvalidasikan
model
tersebut
untuk
menjamin agar strukturnya benar (menggunakan
teknik normalisasi) dan mendukung transaksi
yang dibutuhkan.
Langkah 2.1 Menghilangkan fitur-fitur yang tidak kompatibel
dengan relational model (tahap optional)
Pada tahap ini, struktur ditransformasikan ke
bentuk yang lebih mudah ditangani oleh sistem.
Tujuan dari tahap ini adalah:
1. Menghilangkan tipe relasi biner many-to-many
(*:*)
2. Menghilangkan tipe relasi rekursif many-tomany (*:*)
3. Menghilangkan tipe relasi kompleks
4. Menghilangkan atribut yang multi-valued
Langkah 2.2 Mendapatkan relasi untuk model data logikal
lokal
Bertujuan untuk membuat relasi untuk model
data logika lokal untuk mewakili entitas, relasi
dan atribut yang telah diidentifikasi. Berbagai
35
relasi yang dapat dihasilkan dari struktur model
data, diantaranya :
- Tipe entitas kuat
- Tipe entitas lemah
- Tipe relasi binari one-to-many (1 : *)
- Tipe relasi binari one-to-one (1 : 1)
- Relasi rekursif one-to-one (1 : 1)
- Tipe relasi superclass / subclass
- Tipe relasi binari many-to-many (* : *)
- Tipe relasi kompleks
- Atribut multi-valued
Langkah 2.3 Validasi relasi menggunakan normalisasi
Bertujuan untuk memvalidasikan relasi di dalam
model data logikal lokal menggunakan teknik
normalisasi. Proses normalisasi terdiri dari
Unnormal Form (UNF), First Normal Form
(1NF), Second Normal Form (2NF) dan Third
Normal Form (3NF).
Langkah 2.4 Validasi relasi dengan transaksi pengguna
Tujuan untuk memastikan bahwa relasi di dalam
model data logikal lokal mendukung kebutuhan
transaksi bagi view. Validasi transaksi seperti ini
sudah dilakukan pada langkah 1.8, namun
dilakukan kembali untuk mengecek relasi – relasi
36
yang diciptakan pada rancangan logikal juga
mendukung transaksi user.
Langkah 2.5 Mendefinisikan batasan integritas (integrity
constraints)
Bertujuan untuk mengecek batas integritas yang
direpresentasikan kedalam model data logikal.
Ada 6 tipe batasan integritas, yaitu:
1. Required data
Beberapa atribut harus memiliki sebuah nilai
yang valid (tidak mengandung null). Contoh :
setiap anggota staf harus memiliki hubungan
posisi job (seperti supervisor atau asisten).
2. Attribute domain constraints
Setiap atribut memiliki sebuah domain. Dengan
kata lain sekumpulan nilai harus sah. Contoh :
jenis kelamin untuk anggota staff boleh ‘M’ atau
‘F’, jadi domain atribut untuk jenis kelamin
adalah karakter tunggal. Batasan ini harus
diidentifikasi dalam kamus data.
3. Multiplicity
Multiplicity merepresentasikan batasan relasi data
di dalam sistem basis data.
4. Entity integrity
37
Primary key dari sebuah entitas tidak boleh null.
Contoh: setiap baris dari relasi staff harus
memiliki nilai untuk
atribut primary key.
5. Referential integrity
Foreign key menghubungkan setiap baris dari
relasi anak untuk baris kedalam relasi induk
dengan
mencocokkan
candidate
key-nya.
Referential integrity maksudnya adalah jika
foreign key berisi sebuah nilai, yang nilainya
harus menunjukan baris yang ada pada relasi
induknya.
6. General constraints
Terakhir, batasan umum harus diperhatikan.
Meng-update entitas mungkin dikontrol oleh
yang memiliki hak pembatas.
Langkah 2.6 Meninjau kembali model data logikal lokal
dengan pengguna
Bertujuan untuk memastikan bahwa model data
logikal lokal dan dokumen pendukung yang
mendeskripsikan model yang sesuai dengan view.
Model
data
logikal
telah
selesai
dan
didokumentasikan. Pada tahapan ini, model
logikal dan dokumentasi tersebut di-review
dengan user.
38
Langkah 3 Membangun dan Melakukan Validasi Model Data
Logikal Global
Bertujuan untuk mengkombinasikan model data
logikal lokal individu menjadi sebuah model data
logikal global yang mewakili perusahaan.
Langkah 3.1 Menggabungkan model data logikal lokal ke
model global
Bertujuan untuk menggabungkan model data
logikal lokal kedalam model data logikal global
yang merepresentasikan semua user view dari
sebuah sistem basis data. Kegiatan dalam tahap
ini terdiri dari:
1. Menggabungkan model data logikal lokal ke
dalam model global.
2. Memvalidasikan model data logikal global
3. Meninjau kembali model data logikal global
dengan user
Langkah 3.2 Validasi model data logikal global
Bertujuan untuk melakukan validasi relasi-relasi
yang dibuat dari model data logikal global
dengan menggunakan teknik normalisasi dan
menjamin relasi tersebut mendukung transaksi
yang diperlukan, jika diperlukan.
Langkah 3.3 Memeriksa untuk perkembangan kedepan
39
Bertujuan untuk menentukan adanya perubahan
dan menilai apakah model data logikal bisa
menampung perubahan ini.
Langkah 3.4 Meninjau kembali model data logikal global
dengan
pengguna
Bertujuan untuk menjamin bahwa model data
logika global adalah perwakilan yang benar dari
sebuah perusahaan.
2.7.11.3 Perancangan Basis Data Fisikal
Menurut Thomas M. Connolly dan Carolyn Begg (2010,
p467), perancangan sistem basis data fisikal adalah suatu
proses menghasilkan deskripsi dari implementasi sistem basis
data pada media sekunder yang menjelaskan relasi dasar,
organisasi file, dan indeks yang digunakan untuk mengakses
data seefisien mungkin dan batasan-batasan integritas yang
diasosiasikan serta ukuran keamanannya.
Langkah 4 Menerjemahkan Model Data Logikal Global untuk
Target DBMS
Bertujuan untuk menghasilkan skema basis data
relasional dari model data logikal global yang
dapat diimplementasikan pada DBMS pilihan.
Bagian pertama dari proses ini memerlukan
perbandingan informasi yang dikumpulkan selama
perancangan sistem basis data logikal dan
40
didokumentasikan pada kamus data. Bagian kedua
dari proses ini menggunakan informasi tersebut
untuk menghasilkan desain relasi dasar. Proses ini
memerlukan
pengetahuan
yang
mendalam
mengenai fungsionalitas yang ditawarkan oleh
DBMS pilihan.
Langkah 4.1 Merancang relasi-relasi dasar
Bertujuan untuk memutuskan relasi dasar yang
diidentifikasikan pada model data logikal global
ke
dalam
target
DBMS.
Untuk
memulai
perancangan fisikal, pertama harus menyusun dan
memahami
informasi
tentang
relasi
yang
menghasilkan perancangan sistem basis data
logikal. Kebutuhan informasi ini bisa berupa
kamus
data
dan
definisi
relasi
yang
menggambarkan penggunaan Database Design
Language (DBDL).
Langkah 4.2 Merancang perwakilan dari data yang didapat
(derived data)
Bertujuan untuk merepresentasikan semua data
yang telah didapat pada model data logikal global
kedalam DBMS pilihan. Atribut yang nilainya
dapat diperoleh dengan memeriksa nilai dari
atribut lain disebut atribut yang didapat atau
atribut hasil kalkulasi. Langkah pertama adalah
41
memeriksa model data logikal dan kamus data
untuk menghasilkan daftar semua atribut yang
didapat. Pada perancangan sistem basis data
fisikal, atribut yang telah diperoleh dapat
disimpan di dalam sistem basis data atau
dikalkulasikan setiap kali diperlukan. Perancang
harus memperhatikan biaya tambahan untuk
menyimpan data yang telah diperoleh dan
menjaganya agar tetap konsisten dengan data
operasional dari mana data tersebut diperoleh
atau
biaya
untuk
mengkalkulasikan atribut
tersebut setiap kali diperlukan.
Langkah 4.3 Merancang batasan perusahaan (enterprise
constraints)
Bertujuan untuk merancang batasan perusahaan
pada DBMS pilihan. Update terhadap data dapat
dibatasi oleh aturan perusahaan yang mengatur
transaksi “dunia nyata”. Perancangan batasan ini
tergantung pada pemilihan DBMS yang akan
digunakan.
Beberapa
DBMS
menyediakan
fasilitas ini, namun ada juga yang tidak
menyediakannya sehingga untuk menentukan
batasan harus dilakukan pada program aplikasi.
Langkah 5 Merancang perwakilan fisikal
42
Bertujuan untuk menentukan organisasi file yang
optimal untuk menyimpan relasi dasar dan indeks
yang diperlukan untuk mendapatkan performa yang
dapat diterima, yang mana adalah sebuah cara
dalam
relasi
yang
akan
ditangani
pada
penyimpanan secondary.
Langkah 5.1 Menganalisa transaksi
Bertujuan untuk memahami fungsi transaksi yang
akan dijalankan pada sistem basis data dan
analisis transaksi yang penting. Dalam analisis
transaksi, terdapat beberapa kriteria diantaranya:
1.
Transaksi yang sering dijalankan akan
memiliki pengaruh yang penting pada hasil.
2. Transaksi yang kritis untuk beroperasi pada
bisnis
3. Waktu selama harian atau mingguan ketika
dapat meningkatkan permintaan pada sistem
basis data
Langkah 5.2 Memilih organisasi file
Bertujuan untuk menentukan organisasi file yang
efisien untuk setiap relasi dasar. Salah satu tujuan
utama dalam perancangan sistem basis data
fisikal adalah untuk menyimpan dan mengakses
data dengan jalur yang efisien.
Langkah 5.3 Memilih indeks
43
Bertujuan
untuk
menentukan
dengan
penambahan indeks akan meningkatkan performa
dari sistem atau tidak. Kriteria memilih atribut
untuk ordering atau clustering tuple, antara lain:
a. Atribut yang paling sering digunakan untuk
operasi join sehingga operasi join tersebut
menjadi lebih efisien, atau
b. Atribut yang paling sering digunakan untuk
mengakses tuple pada sebuah tabel berdasarkan
urutan atribut tersebut.
Jika urutan ordering yang dipilih adalah kunci
dari tabel, indeks akan menjadi primary index
namun jika bukan kunci, indeks akan menjadi
clustering index. Indeks sekunder menyediakan
sebuah mekanisme untuk menspesifikasikan key
tambahan
untuk
relasi
dasar
yang
dapat
digunakan untuk mengambil data lebih efisien.
Langkah 5.4 Memperkirakan kebutuhan kapasitas disk
Bertujuan untuk memperkirakan jumlah kapasitas
disk yang akan dibutuhkan oleh sistem basis data.
Memperkirakan
penggunaan
kapasitas
disk
tergantung pada DBMS yang dipakai dan
perangkat
keras
yang
digunakan
untuk
mendukung sistem basis data. Secara umum,
estimasi didasarkan pada ukuran setiap baris dan
44
jumlah baris dalam setiap tabel. Selain itu perlu
juga dipertimbangkan apakah setiap tabel akan
bertumbuh
pertumbuhan
dan
ini
sebaiknya
akan
faktor
ke
dalam
dimasukkan
perhitungan kebutuhan kapasitas disk.
Langkah 6 Merancang view pengguna
Bertujuan untuk merancang user view yang
diidentifikasi
selama
tahapan
pengumpulan
kebutuhan dan analisis dari siklus aplikasi sistem
basis data. User view mendefinisikan apa yang
dibutuhkan dari aplikasi sistem basis data dari
sudut pandang jabatan tertentu (misalnya manajer
atau supervisor) atau area aplikasi perusahaan
(seperti pemasaran, personalia, atau pengendalian
stok). Perancangan dari user view individual harus
didokumentasikan secara lengkap.
Langkah 7 Merancang mekanisme keamanan
Bertujuan untuk merancang mekanisme keamanan
untuk sistem basis data yang dispesifikasi oleh
user.
- Keamanan Sistem
45
Meliputi akses dan penggunaan sistem basis data
pada tingkatan sistem seperti username dan
password.
- Keamanan Data
Meliputi akses dan penggunaan objek sistem basis
data (seperti relasi dan view) dan tindakan yang
memungkinkan user untuk memanipulasi objek.
Langkah 8 Mempertimbangkan pengenalan dari redundansi
yang terkontrol
Bertujuan untuk menentukan apakah penerapan
redundansi
dalam
situasi
terkontrol
dengan
mengurangi aturan normalisasi akan meningkatkan
performa sistem. Seringkali rancangan sistem basis
data
yang
menyediakan
maksimum
ternormalisasi
efisiensi
sehingga
tidak
mampu
pemrosesan
denormalisasi
yang
dilakukan
untuk mencapai performa yang diinginkan. Namun
perlu dipertimbangkan beberapa faktor
berikut:
a.
Denormalisasi
menyebabkan
implementasi
menjadi lebih kompleks.
b.
Denormalisasi
fleksibilitas.
seringkali
mengurangi
46
c. Denormalisasi dapat mempercepat pengambilan
data
namun memperlambat update.
Denormalisasi untuk mempercepat transaksi yang
sering dilakukan atau transaksi kritis dapat
diaplikasikan pada situasi berikut:
1. Menggabungkan one-to-one (1 : 1)
Menguji kembali relasi one-to-one (1 : 1)
menentukan efek dari kombinasi relasi kedalam
relasi
tunggal.
Kombinasi
seharusnya
hanya
memperhatikan untuk relasi yang sering direlasi
dan yang tidak sering direlasikan.
2. Menduplikasi atribut – atribut yang bukan kunci
di dalam relasi one to many (1 : *) untuk
mengurangi join.
3. Menduplikasi atribut – atribut foreign key
didalam relasi one to many (1: *)
4. Menduplikasi atribut dalam many to many (* : *)
relasi untuk mengurangi join
5. Mempelajari kelompok repetisi
6. Membuat tabel kutipan
7. Membagi relasi
Langkah 9 Mengawasi (monitor) dan tuning sistem operasi
Bertujuan untuk mengawasi sistem operasional dan
meningkatkan performa sistem untuk memperbaiki
47
keputusan rancangan yang kurang tepat atau
adanya perubahan kebutuhan. Perancangan awal
sistem basis data secara fisikal seharusnya tidak
dianggap statis, melainkan harus dipertimbangkan
sebagai sebuah perkiraan dari kinerja operasional.
Setelah perancangan awal telah diimplementasikan,
maka
diperlukan
pengawasan
sistem
dan
penyetelannya sebagai hasil dari pengamatan
kinerja dan perubahan kebutuhan.
2.8 Diagram Konteks
Diagram konteks merupakan level tertinggi di dalam Data Flow Diagram
yang hanya terdiri dari satu simbol proses yang menggambarkan sistem secara
keseluruhan. Diagram konteks berisi gambaran umum (secara garis besar) sistem
yang akan dibuat.
Diagram konteks berisi “siapa saja yang memberi data (dan data apa saja)
ke sistem, serta kepada siapa saja informasi (dan informasi apa saja) yang harus
dihasilkan sistem.” Jadi, yang dibutuhkan adalah
(1) Siapa saja pihak yang akan memberikan data ke sistem.
(2) Data apa saja yang diberikannya ke sistem.
(3) Kepada siapa sistem harus memberi informasi atau laporan.
(4) Apa saja isi/ jenis laporan yang harus dihasilkan sistem.
Kata “Siapa” di atas dilambangkan dengan kotak persegi (disebut dengan
terminator), dan kata “apa” di atas dilambangkan dengan aliran data (disebut
dengan data flow), dan kata “sistem” dilambangkan dengan lingkaran (disebut
dengan process).
48
Gambar 2.2 Elemen Diagram Konteks
2.9 Use Case Diagram
•
Definisi
Mengacu pada pendapat Jason T.Roff (2003) pengertian use case
diagram dapat dikemukakan sebagai berikut :
− Use case diagram digunakan untuk memodelkan dan menyatakan
unit fungsi/layanan yang disediakan oleh sistem (atau bagian sistem :
subsistem atau class) ke pemakai.
− Use case diagram dapat dilingkupi dengan batasan sistem yang
diberi label nama sistem.
− Use case diagram adalah sesuatu yang menyediakan hasil yang dapat
diukur ke pemakai atau sistem eksternal.
•
Karakteristik :
− Use case diagram adalah interaksi atau dialog antara sistem dan
actor, termasuk pertukaran pesan dan tindakan yang dilakukan oleh
sistem.
49
− Use case diagram diprakarsai oleh actor dan mungkin melibatkan
peran actor lain. Use case harus menyediakan nilai minimal kepada
satu actor.
− Use case diagram bisa memiliki perluasan yang mendefinisikan
tindakan khusus dalam interaksi atau use case lain mungkin
disisipkan.
− Use case diagram memiliki objek use case yang disebut skenario.
Skenario menyatakan urutan pesan dan tindakan tunggal.
•
Komponen Pembentuk Use Case Diagram
1. Actor
Pada dasarnya actor bukanlah bagian dari use case diagram, namun
untuk dapat terciptanya suatu use case diagram diperlukan beberapa
actor.
Mengacu
pada
pendapat
Jason
T.Roff
(2003)
actor
mempresentasikan seseorang atau sesuatu (seperti perangkat, sistem lain)
yang berinteraksi dengan sistem. Sebuah actor mungkin hanya
memberikan informasi inputan pada sistem, hanya menerima informasi
dari sistem atau keduanya menerima, dan memberi informasi pada sistem.
Actor hanya berinteraksi dengan use case, tetapi tidak memiliki
kontrol atas use case. Actor digambarkan dengan stick man . Actor dapat
digambarkan secara secara umum atau spesifik, dimana untuk
membedakannya kita dapat menggunakan relationship.
50
Gambar 2.3 : Gambar Actor
2. Use Case
Mengacu pada pendapat Jason T.Roff (2003) use case dapat
dikemukakan sebagai suatu gambaran fungsionalitas dari suatu sistem,
sehingga customer atau pengguna sistem paham dan mengerti mengenai
kegunaan sistem yang akan dibangun.
Catatan : Use case diagram adalah penggambaran sistem dari sudut
pandang pengguna sistem tersebut (user), sehingga pembuatan Ude case
lebih dititikberatkan pada fungsionalitas yang ada pada sistem, bukan
berdasarkan alur atau urutan kejadian.
•
Cara menentukan Use Case dalam suatu sistem
a) Pola perilaku perangkat lunak aplikasi.
b) Gambaran tugas dari sebuah actor.
c) Sistem atau “benda” yang memberikan sesuatu yang
bernilai kepada actor.
d) Apa yang dikerjakan oleh suatu perangkat lunak (bukan
bagaimana cara mengerjakannya).
Gambar 2.4 : Gambar Use Case
•
Relasi dalam Use Case
Ada beberapa relasi yang terdapat pada use case diagram :
51
a) Association, menghubungkan link antar element. Generalization,
disebut juga inheritance (pewarisan), sebuah elemen dapat merupakan
spesialisasi dari elemen lainnya.
b) Dependency, sebuah element bergantung dalam beberapa cara ke
element lainnya.
c) Aggregation, bentuk assosiation dimana sebuah elemen berisi elemen
lainnya.
•
Tipe relasi / stereotype yang mungkin terjadi pada use case diagram
a) include : kelakuan yang harus terpenuhi agar sebuah event dapat
terjadi, dimana pada kondisi ini sebuah use case adalah bagian dari
use case lainnya.
b) extends : kelakuan yang hanya berjalan di bawah kondisi tertentu
seperti menggerakkan alarm.
c) communicates
:
mungkin
ditambahkan
untuk
asosiasi
yang
menunjukkan asosiasinya adalah communicates association . Ini
merupakan pilihan selama asosiasi hanya tipe relationship yang
dibolehkan antara actor dan use case.
52
•
Contoh Use Case Diagram pada sistem perbankan
Gambar 2.5 : Contoh Use Case Diagram
2.10 Class Diagram
Mengacu pada pendapat Jason T.Roff (2003) class diagram dapat
dikemukakan sebagai suatu gambaran struktur dan deskripsi class, package, dan
objek beserta hubungan satu sama lain seperti hubungan dinamis, pewarisan,
asosiasi, dan agregasi. Sesuai perkembangan class model, class dapat
dikelompokkan menjadi package. Sehingga dapat membuat diagram yang terdiri
atas package.
•
Bagian Class Diagram
Class Diagram memiliki tiga area pokok :
− Nama (dan stereotype)
− Atribut
− Metode
53
Gambar 2.6 : Contoh Class Diagram
•
Komponen Class Diagram
Class Diagram mempunyai 3 komponen, antara lain :
a. Entity Classes
o Segala sesuatu (concrete, conceptual, event dan state)
dapat dijadikan suatu entity dalam suatu class.
o Metode penentuan Entity Class
− Client Interview
− Mempelajari dokumen yang sudah ada
b. Interfaces Classes
o Pada Interfaces Classes terdapat 3 komponen
pendukung, antara lain :
− User Interface
− Data Communication Interfaces
− Sistem Control
54
o Class dapat merupakan implementasi dari sebuah
interface, yaitu class abstrak yang hanya memiliki
metoda.
o Interface tidak dapat langsung diinstanisasi, tetapi
harus diimplementasi dahulu menjadi sebuah class.
Dengan demikian interface pendukung resolusi
metoda pada saat run time.
c. Control Classes
Control classes merupakan suatu class yang difungsikan
untuk mengatur Entity Classes dan Interfaces Classes.
•
Hubungan antar Class
o Asosiasi
Hubungan statis antar class. Umumnya menggambarkan class
yang memiliki atribut berupa class lain atau class yang harus
mengetahui eksistensi class lain. Panah navigability menunjukkan
arah query antar class.
o Agregasi
Hubungan yang menyatakan bagian (“terdiri atas..”). Beberapa
class dapat mempunyai hubungan agregasi jika salah satu class
berisi atribut-atribut yang ada pada class lain.
o Pewarisan
Hubungan hierarki antar class. Class dapat diturunkan dari class
lain dan mewarisi semua atribut dan metoda class asalnya dan
menambahkan fungsionalitas baru, sehingga ia disebut anak dari
55
class yang diwarisinya. Kebalikan dari pewarisan adalah
generalisasi.
o Hubungan Dinamis
Rangkaian pesan (message) yang di-passing dari satu class kepada
class
lain.Hubungan
dinamis
dapat
digambarkan
dengan
menggunakan sequence diagram.
2.11 Sequence Diagram
Mengacu pada pendapat Jason T.Roff (2003) sequence diagram dapat
dikemukakan sebagai suatu diagram yang menggambarkan interaksi antar
obyek dan mengindikasikan komunikasi diantara obyek-obyek tersebut.
Sequence diagram ini juga menunjukkan serangkaian pesan yang dipertukarkan
oleh obyek-obyek yang melakukan suatu tugas atau aksi tertentu. Obyek-obyek
tersebut kemudian diurutkan dari kiri ke kanan, aktor yang menginisiasi
interaksi biasanya ditaruh di paling kiri dari diagram.
Pada diagram ini, dimensi vertikal merepresentasikan waktu. Bagian
paling atas dari diagram menjadi titik awal dan waktu berjalan ke bawah
sampai dengan bagian dasar dari diagram. Garis vertikal, disebut lifeline,
dilekatkan pada setiap obyek atau aktor. Kemudian, lifeline tersebut
digambarkan menjadi kotak ketika obyek melakukan suatu operasi, kotak
tersebut disebut activation box. Obyek dikatakan mempunyai live activation
pada saat tersebut.
Pesan yang dipertukarkan antar obyek digambarkan sebagai sebuah anak
panah antara activation box pengirim dan penerima. Kemudian diatasnya
diberikan label pesan. Salah satu contoh sequence diagram digambarkan
sebagai berikut :
56
Gambar 2.7 : Gambar Sequence Diagram
Tujuan penggunaan sequence diagram
o Mengkomunikasikan requirement kepada tim teknis karena diagram ini
dapat lebih mudah untuk dielaborasi menjadi model design.
o
Merupakan diagram yang paling cocok untuk mengembangkan model
deskripsi usecase menjadi spesifikasi design.
2.12 Eight Golen Rules
Mengacu pada pendapat Ben Shneiderman dan Catherine Plaisant (2010)
mengemukakan 8 (delapan) aturan yang dapat digunakan sebagai petunjuk
dasar yang baik untuk merancang suatu user interface. Delapan aturan ini
disebut dengan Eight Golden Rules of Interface Design, yaitu :
1. Konsistensi
Konsistensi dilakukan pada urutan tindakan, perintah, dan istilah yang
digunakan pada prompt, menu, serta layar bantuan.
2. Memungkinkan pengguna untuk menggunakan shortcut
57
Ada kebutuhan dari pengguna yang sudah ahli untuk meningkatkan
kecepatan interaksi, sehingga diperlukan singkatan, tombol fungsi,
perintah tersembunyi, dan fasilitas makro.
3. Memberikan umpan balik yang informatif
Untuk setiap tindakan operator, sebaiknya disertakan suatu sistem
umpan balik. Untuk tindakan yang sering dilakukan dan tidak terlalu
penting, dapat diberikan umpan balik yang sederhana. Tetapi ketika
tindakan merupakan hal yang penting, maka umpan balik sebaiknya
lebih substansial. Misalnya muncul suatu suara ketika salah menekan
tombol pada waktu input data atau muncul pesan kesalahannya.
4. Merancang dialog untuk menghasilkan suatu penutupan
Urutan tindakan sebaiknya diorganisir dalam suatu kelompok dengan
bagian awal, tengah, dan akhir. Umpan balik yang informatif akan
memberikan indikasi bahwa cara yang dilakukan sudah benar dan dapat
mempersiapkan kelompok tindakan berikutnya.
5. Memberikan penanganan kesalahan yang sederhana
Sedapat mungkin sistem dirancang sehingga pengguna tidak dapat
melakukan kesalahan fatal. Jika kesalahan terjadi, sistem dapat
mendeteksi kesalahan dengan cepat dan memberikan mekanisme yang
sedehana dan mudah dipahami untuk penanganan kesalahan.
6. Mudah kembali ke tindakan sebelumnya
Hal ini dapat mengurangi kekhawatiran pengguna karena pengguna
mengetahui kesalahan yang dilakukan dapat dibatalkan, sehingga
58
pengguna tidak takut untuk mengekplorasi pilihan-pilihan lain yang
belum biasa digunakan.
7. Mendukung tempat pengendali internal (internal locus of control)
Pengguna ingin menjadi pengontrol sistem dan sistem akan merespon
tindakan yang dilakukan pengguna daripada pengguna merasa bahwa
sistem mengontrol pengguna. Sebaiknya sistem dirancang sedemikian
rupa sehingga pengguna menjadi inisiator daripada responden.
8. Mengurangi beban ingatan jangka pendek
Keterbatasan ingatan manusia membutuhkan tampilan yang sederhana
atau banyak tampilan halaman yang sebaiknya disatukan, serta
diberikan cukup waktu pelatihan untuk kode, mnemonic, dan urutan
tindakan.