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.
