7

BAB 2

LANDASAN TEORI

2.1 Teori Umum

2.1.1 Teori Pembangkit Soal Ujian

A. Pengertian Pembangkit Soal Ujian

Menurut http://www.testshop.com, ”Pembangkit soal ujian adalah

program komputer atau software yang memberikan kemudahan bagi trainer dan

pengajar dengan menyederhanakan keseluruhan proses penciptaan, penyebaran,

dan administrasi untuk dalam penyusunan set soal ujian, bersumber pada

database soal yang besar.”.

Menurut http://www.conformiq.com/ctg.php, pembangkit soal ujian akan

meningkatkan efisiensi kerja dengan menggantikan cara manual dengan cara

design baru yang lebih tinggi levelnya.

Menurut http://www.softempire.com/random-test-generator-pro.html,

pembangkit soal ujian dirancang bagi kalangan pengajar pada tingkat manapun

untuk mengembangkan sebuah bank soal yang berisi pertanyaan-pertanyaan

dengan standar tertentu yang nantinya akan diekstrak dan dibuat menjadi sebuah

set soal ujian.

B. Fitur-Fitur Pada Pembangkit Soal Ujian

Fitur yang biasa terdapat pada pembangkit soal menurut

http://www.easytestmaker.com dan http://www.economicsnetwork.ac.uk/teaching

/gaptool.htm

8

1. Menciptakan dua atau lebih versi yang berbeda dari set soal yang asli,

dalam hal ini berarti menciptakan kombinasi set soal.

2. Memberikan kemudahan untuk meng-copy pertanyaan dari set soal yang

satu ke set soal yang lain.

3. Memberikan kemudahan untuk membuat salinan lengkap dari set-set soal

dan menyimpannya dengan nama yang berbeda.

4. Memberikan kemudahan untuk membuat lembar jawaban secara

otomatis.

5. Memberikan kemudahan untuk mengubah set soal ke format tertentu

seperti .doc maupun .pdf.

6. Memberikan kemudahan untuk mengecek ejaan dan tata bahasa sebelum

proses pencetakan soal.

7. Memberikan kemudahan dalam memasukkan gambar atau bagan pada

setiap soal.

8. Memberikan jaminan keamanan dengan login dan password dan

melarang tindakan print screen dan copy paste terhadap set soal yang

ada.

2.1.2 Tipe Soal

Terdapat lima tipe soal menurut http://www.herts.ac.uk/ltdu/pdp/resources/

tutorials/assessment/generator.pdf, yaitu :

1. True or False (Benar atau Salah)

Tipe soal dimana pembuat soal menyediakan sebuah pertanyaan beserta dua

pilihan jawaban, yaitu benar atau salah.

9

2. Pilihan Ganda

Tipe soal dimana pembuat soal dapat menginput pertanyaan dan memberikan

sejumlah pilihan jawaban, dengan satu pilihan adalah jawaban yang benar, dan

pilihan jawaban yang lain adalah jawaban pengecoh.

3. Mengisi bagian yang kosong

Tipe soal dimana pembuat soal dapat menginput pertanyaan dalam bentuk

kalimat atau paragraf dan mengosongkan bagian tertentu untuk diisi oleh

peserta ujian.

4. Menjodohkan

Tipe soal dimana pembuat soal harus memberikan instruksi atau soal-soal

awal, dan juga memberikan sejumlah pilihan jawaban dari soal-soal tersebut

secara acak.

5. Uraian

Tipe soal dimana pembuat soal memberikan pertanyaan, baik berupa

pertanyaan yang membutuhkan jawaban singkat, jawaban uraian, maupun

pertanyaan yang berupa kasus dan membutuhkan jawaban dengan tingkat

analisa yang lebih dalam.

2.2 Teori Khusus

2.2.1 Teori Basis Data

A. Pengertian Data

Menurut James O’Brien (2004, p7), “Data are raw facts or observations,

typically about physical phenomena or business transactions. More specifically

data are objective measurements of the attributes of entities”. Jadi data dapat

10

diartikan sebagai fakta mentah atau hasil pengamatan mengenai kejadian fisik

atau transaksi bisnis. Secara lebih spesifik data adalah ukuran tujuan atribut dari

suatu entitas.

B. Pengertian Basis Data (Database)

Menurut Date (1990, p10) “A database is a collection of persistent data

that is used by the application systems of some given enterprise.”, yang artinya

basis data adalah sekumpulan dari data tetap yang digunakan oleh sistem aplikasi

dari perusahaan.

Menurut Connolly (2005, p14) “Database, a shared collection of

logically related data, and a description of this data, designed to meet the

information needs of an organization.” yang artinya basis data merupakan

kumpulan data yang saling berhubungan secara logikal, yang didesain untuk

menampilkan informasi yang dibutuhkan oleh suatu organisasi.

Menurut Kroenke (2006, p11) “A Database is a self-describing collection

of integrated tables”, yang artinya basis data adalah kumpulan dari tabel-tabel

terintegrasi yang mendeskripsikan dirinya sendiri.

Pengguna dari sistem dapat melakukan beberapa operasi pada file – file

seperti dibawah ini:

Menambah file baru ke sistem basis data.

Memasukkan data kedalam file yang tersedia.

Mengambil, mengubah, atau menghapus data dari file.

Menghapus file yang ada dalam basis data.

11

C. Database Management System (DBMS)

Menurut Gehrke (2003, p4) “DBMS is a software that designed to assist

in maintaining and utilizing large collection of data.”, yang artinya DBMS

merupakan perangkat lunak yang dirancang untuk membantu dalam memelihara

dan penggunaan koleksi data yang besar.

Menurut Connolly (2005, p16) “DBMS is a software that enables users

to define, create, maintain and control access to the database.”, yang artinya

sistem manajemen basis data merupakan sistem perangkat lunak yang

memungkinkan pengguna untuk mendefinisikan, membuat, memelihara dan

mengkontrol akses ke basis data.

Tiga jenis arsitektur Multi-User DBMS :

Teleprocessing

Arsitektur teleprocessing termasuk arsitektur yang bersifat tradisional,

dan hanya memiliki satu mainframe dengan sejumlah terminal yang

berhubungan.

File-Server

File-Server dihubungkan ke beberapa workstations melalui jaringan.

Database terletak dalam file-server, sedangkan DBMS dan aplikasi berjalan

pada tiap workstations. Kelemahannya terletak pada arus lalu lintas jaringan

yang signifikan, tiruan DBMS pada tiap workstations, dan tingkat

konkurensi, perbaikan, dan integritas yang lebih kompleks.

12

Client-Server

Dalam arsitektur model Client-Server ini, database dan DBMS terletak

pada server, dan pihak client memiliki kewenangan terhadap pengaturan user

interface dan dalam menjalankan aplikasi.

Keuntungan menggunakan arsitektur Client-Server :

o Akses yang lebih luas ke database yang telah ada,

o Performa yang lebih meningkat,

o Kemungkinan terjadinya pengurangan terhadap biaya hardware,

o Pengurangan biaya komunikasi,

o Konsistensi yang meningkat.

D. Komponen Database Management System

Menurut Connolly (2005, p18), DBMS punya 4 komponen utama dalam

sebuah sistem, yaitu:

Perangkat Keras (Hardware)

Berupa komputer pribadi, mainframe tunggal, sampai komputer jaringan.

Perangkat Lunak (Software)

Terdiri dari perangkat lunak DBMS itu sendiri dan program aplikasi,

bersama-sama dengan sistem operasi, termasuk perangkat lunak jaringan.

Data

Data berperan sebagai jembatan antara komponen mesin dan manusia. Basis

data terdiri dari data operasional dan meta-data, data tentang data itu sendiri.

13

Prosedur

Prosedur mengacu pada instruksi dan aturan-aturan yang menentukan desain

dan penggunaan basis data.

Pengguna

Komponen terakhir dari DBMS adalah orang yang terkait dengan sistem.

E. Model Data dan Entity Relationship Modeling (ERM)

Menurut Silberschatz, Korth, Sudarshan (2002, p7), ”data model : a

collection of conceptual tools for describing data, data relationship, data

semantics, and consistency constraints.” yang artinya model data adalah koleksi

dari alat konseptual untuk menggambarkan data, hubungan data, semantic data,

dan batasan konsistensi.

Terdapat empat jenis model data :

Object-based Data Models

Permodelan data yang mengutamakan entity relationship, semantic,

functional, dan object-oriented.

Record-based Data Models

Permodelan data yang mengutamakan Relational Data Model, Network Data

Model, dan Hierarchical Data Model.

Physical Data Models

Berisi penjelasan bagaimana data disimpan dalam komputer, menampilkan

informasi dalam struktur record, mengurutkan record, dan jalur akses.

14

Conceptual Modeling

Merupakan proses konstruksi arsitektur database secara detail terlepas dari

rincian implementasinya. Desain konseptual ini sangat penting bagi

kesuksesan menyeluruh suatu sistem.

Menurut Connolly (2005, p342) “ERM is a top-down approach to

database design that begins by identifying the important data called entities and

relationships between the data that must be represented in the model.”, yang

artinya ERM merupakan pendekatan atas-bawah pada perancangan basis data

yang dimulai dengan mengidentifikasikan data penting yang disebut entitas dan

relasi antara data yang harus direpresentasikan dalam model.

a. Tipe Entitas (Entity Type)

Menurut Connolly (2005, p343) “Entity type is a group of objects with

the same properties, which are identified by the enterprise as having an

independent existence.”, yang artinya tipe entitas adalah sekelompok obyek yang

memiliki properti yang sama, dimana diidentifikasikan oleh suatu perusahaan

seperti memiliki keberadaan yang independen.

Menurut Connolly (2005, p344) tipe entitas dapat digolongkan menjadi 2

yaitu entitas kuat dan entitas lemah. Tipe entitas kuat adalah tipe entitas yang

keberadaannya tidak bergantung pada beberapa entitas lain. Sedangkan tipe

entitas lemah adalah tipe entitas yang keberadaannya bergantung pada beberapa

entitas lainnya.

15

b. Tipe Relasi (Relationship Type)

Menurut Connolly (2005, p346) “Relationship type is a set of meaningful

associations among entity types.”, yang artinya tipe relasi adalah sekelompok

relasi yang berarti antar tipe-tipe entitas.

c. Atribut (Attribute)

Menurut Connolly (2005, p350) “Attribute is a property of an entity or

a relationship type.”, yang artinya atribut adalah properti dari suatu entitas atau

tipe relasi. Setiap atribut dihubungkan dengan sekelompok nilai yang disebut

domain (attribute domain).

d. Kunci (Key)

Menurut Connolly (2005, p352), ada 3 jenis kunci:

1. Kunci kandidat (Candidate key) : sekelompok atribut minimal yang

secara unik mengidentifikasikan keberadaan suatu tipe entitas.

2. Kunci utama (Primary key) : kunci kandidat yang dipilih untuk

mengidentifikasikan setiap keberadaaan tipe entitas secara unik.

3. Kunci gabungan (Composite key) : kunci kandidat yang terdiri dari dua

atribut atau lebih.

e. Structural Constraint

Menurut Connolly (2005, p356) aturan-aturan struktural harus

merefleksikan pembatasan dari hubungan seperti halnya di dunia nyata.

Tipe aturan utama dalam relasi disebut keserbaragaman (multiplicity).

Keserbaragaman adalah bilangan keberadaan yang mungkin dari tipe entitas

yang mungkin menghubungkan keberadaan tunggal dari tipe entitas yang

berhubungan melalui relasi tertentu.

16

F. Data Definition Language (DDL)

Menurut Connolly (2005, p40) “DDL is a language that allows the DBA

or user to describe and name the entities, attributes, and relationships required

for the application, together with any associated integrity and security

constraint.”, yang artinya DDL adalah bahasa yang mengijinkan pengurus basis

data atau pengguna untuk menggambarkan dan memberi nama entitas, atribut

dan relasi yang dibutuhkan aplikasi, bersamaan dengan integritas yang

berhubungan dan aturan keamanan.

G. Data Manipulation Language (DML)

Menurut Connolly (2005, p41) “DML is a language that provides a set of

operations to support the basic data manipulation operations on the data held in

the database.”, yang artinya DML adalah bahasa yang menyediakan seperangkat

operasi untuk mendukung operasi manipulasi data dasar pada data yang

tersimpan dalam basis data.

H. Normalisasi

Menurut Connolly (2005, p387) “Normalization is a technique for

producing a set of relations with desirable properties, given the data

requirements of an enterprise.”. yang artinya normalisasi adalah teknik untuk

menghasilkan sekelompok relasi dengan properti yang diinginkan, memberikan

data kebutuhan dari suatu perusahaan.

17

Ada 6 tahap normalisasi menurut Connolly (2005, p401) yaitu:

a. Bentuk Normal Pertama (First Normal Form / 1NF)

Definisi Bentuk Normal Pertama menurut Connolly (2005, p403) adalah

sebuah relasi dimana setiap baris dan kolom mempunyai hanya satu nilai.

Dengan mentransfer data dari sumber ke dalam format tersebut dan tabel dalam

bentuk tidak normal (unnormalized form) akan diubah ke bentuk normal pertama

dengan menghilangkan kelompok yang berulang seperti atribut atau sekelompok

atribut.

b. Bentuk Normal Kedua (Second Normal Form / 2NF)

Definisi bentuk Normal Kedua menurut Connolly (2005, p407) adalah

sebuah relasi yang ada pada bentuk normal pertama, dan setiap atribut yang

bukan primary key keterngantungan fungsional penuh pada primary key. Yang

didasarkan pada konsep ketergantungan fungsional secara penuh.

Perubahan dari 1NF ke 2NF ditentukan dengan menghilangkan

ketergantungan parsial. Jika terdapat ketergantungan parsial dilakukan

penghilangan atribut yang tergantung fungsional dengan memindahkan ke dalam

relasi baru dengan duplikasi dari determinannya.

c. Bentuk Normal Ketiga (Third Normal Form / 3NF)

Definisi Bentuk Normal Ketiga menurut Connolly (2005, p408) adalah

sebuah relasi dimana memenuhi 1NF dan 2NF dan dimana atribut tidak primary

key mengalami ketergantungan transitif pada primary key. Dan meskipun relasi

2NF lebih sedikit mengalami pengulangan data daripada 1NF, tidak dipungkiri

masih bisa mengalami update anomalies (relasi yang memiliki data yang

berulang).

18

Normalisasi 2NF ke 3NF dilakukan dengan menghilangkan

ketergantungan transitif. Jika terdapat ketergantungan transitif, maka dihilangkan

dari relasi dengan menempatkan atribut pada suatu relasi yang baru dengan

duplikasi determinannya.

d. Bentuk Normal Boyce-Codd (BCNF)

Menurut Connolly (2005, p419) BCNF adalah suatu relasi jika dan hanya

jika setiap determinan adalah kunci kandidat.

BCNF berdasarkan pada prinsip ketergantungan fungsional. Perbedaan

BCNF dan 3NF adalah jika 3NF memungkinkan sebuah relasi memiliki B

sebagai primary key dan A ketergantungan fungsional terhadap B, A boleh tidak

merupakan kunci kandidat, sedangkan dalam BCNF, A harus merupakan kunci

kandidat.

e. Bentuk Normal Keempat (Fourth Normal Form / 4NF)

Meskipun BCNF menghilangkan anomali dari ketergantungan

fungsional, penelitian lebih lanjut mengidentifikasikan tipe ketergantungan

lainnya yang disebut multi-valued dependency (MVD) yang juga menyebabkan

pengulangan data.

MVD menggambarkan ketergantungan antara atribut dalam suatu relasi,

dimana setiap nilai dari A adalah sekelompok nilai untuk B dan sekelompok nilai

untuk C. Dimana nilai-nilai B dan C tidak tergantung satu sama lain.

Menurut Connolly (2005, p430) Bentuk normal keempat adalah suatu

relasi yang memenuhi BCNF dan tidak mengandung nontrivial multi-valued

dependencies (yang dilakukan dengan pemisahan atribut yang multi- valued

dependency ke relasi yang baru).

19

f. Bentuk Normal Kelima (Fifth Normal Form / 5NF)

Menurut Connolly (2005, p431) Bentuk Normal Kelima adalah suatu

relasi yang tidak memiliki ketergantungan gabungan (join dependency). 5NF ini

sering disebut project-join normal form (PJNF).

Join dependency menggambarkan sebuah tipe ketergantungan.

Contohnya, sebuah relasi R dengan subset dari atribut R menunjuk A, B… Z,

sebuah relasi R memenuhi join dependency jika dan hanya jika setiap nilai resmi

dari R sama dengan penggabungan proyeksi A, B… Z.

I. Denormalisasi

Menurut Connolly (2005, p520) Denormalisasi merupakan perbaikan

pada skema relasional seperti pada tahapan normalisasi, yaitu dengan

memperbaiki relasi yang telah ada dengan cara mengkombinasikan dua buah

relasi ke dalam sebuah relasi yang baru.

Jika performance tidak memuaskan dan sebuah relasi memiliki tingkat

update yang rendah serta frekuensi penggunaan query sangat tinggi maka

denormalisasi akan menjadi pilihan yang baik.

Denormalisasi membuat implementasi yang lebih kompleks dan

mengurangi fleksibilitas. Denormalisasi ini berguna untuk mempercepat proses

retrieval namun memperlambat proses update.

J. Web dan Database

Web memperluas sistem database. Internet dan web dapat memperluas

kapabilitas dari sistem database dalam hal berikut ini:

20

Akses yang lebih luas

Dengan menghubungkan sistem ke internet, pengguna yang potensial dapat

dikembangkan di seluruh dunia.

Pelayanan yang lebih banyak

Internet dapat dihubungkan bersama sistem database yang lain untuk

mendapatkan pelayanan baru.

K. Siklus Hidup Aplikasi Web Database

Metode desain sistem web database terdiri dari seri model yang

menyediakan data disimpan di dalam halaman web, sebagai tambahan untuk data

dalam database. Yang menjadi input adalah analisa abstrak dari informasi untuk

disimpan di dalam database. Output-nya adalah deskripsi fisikal dari bagaimana

database akan diimplementasikan. Tujuannya adalah untuk mendesain database

menggunakan struktur data model yang mendukung DBMS. Seperti database,

struktur web database dapat digambarkan pada tingkat yang berbeda dari

abstraksi, korespon pada konseptual, logikal, dan fisikal model dari sistem

database konvensional.

21

Siklus Hidup Aplikasi Web Database digambarkan seperti di bawah ini :

Gambar 2.1 The Web Database Application Lifecycle

(Sumber: Barry Eaglestone dan Mick Ridley, 2001, p264)

The Organization

Requirements Analysis

Logical WebDatabase Design

Description of The Organization and System Requirements

Data Analysis

Conceptual Data Model

Logical Database Design

Logical Data Model

Web Data Analysis

Logical Web Data Design

Conceptual Web Data Model

Logical Web Data Model

Physical WebDatabase Design

Physical Database Design Physical Web Database Design

Physical Web Data Model

22

Adapun tahapan-tahapan pada siklus hidup aplikasi web basis data adalah

sebagai berikut:

a. The Organization

Menggambarkab keseluruhan ruang lingkup perusahaan atau sistem yang

membutuhkan aplikasi web database.

b. Requirement Collection and Analysis

Proses mengumpulkan dan menganalisa informasi tentang bagian dari

organisasi yang mendukung dari aplikasi basis data, dan penggunaan informasi

untuk mengidentifikasikan kebutuhan pengguna akan sistem yang baru.

c. Description of The Organization and System Requirements

Menggambarkan ruang lingkup dan batasan dari aplikasi basis data dan

bidang pandangan pengguna.

d. Logical Web Database Design

Dalam tahap ini, terdapat tahap-tahap kecil yang membantu proses

perancangan aplikasi web database, yaitu :

1. Data Analysis

Proses yang menyesuaikan dengan struktur organisasinya, tidak

bergantung pada pertimbangan fisiknya. Hasilnya adalah Conceptual Data

Model untuk setiap kebutuhan.

Berikut ini adalah tahapan membangun desain konseptual menurut

Connolly (2005, p1326 – 1328) :

Tahap 1. Membangun data model konseptual lokal untuk setiap kebutuhan,

dengan:

23

o Mendefinisikan tipe entitas.

Mendefinisikan tipe entitas utama yang dibutuhkan berdasarkan

pandangan pengguna terhadap perusahaan.

o Mendefinisikan tipe relasi.

Mengidentifikasikan relasi penting yang ada antara tipe-tipe entitas yang

telah diidentifikasikan sebelumnya. Pada tahap ini juga ditentukan

kardinalitas tiap relasi.

o Mendefinisikan dan menghubungkan atribut dengan entitas atau relasi.

o Menentukan domain atribut.

o Menentukan kunci kandidat dan atribut primary key

o Menentukan kunci kandidat, apabila ada lebih dari satu kunci kandidat,

untuk menentukan satu key untuk menjadi primary key.

o Membandingkan penggunaan enhanced modeling concept(optional).

Pada tahap ini dilakukan pengembangan ER model dengan konsep

pemodelan lanjut seperti spesialisasi atau generalisasi, agregasi dan

komposisi.

o Memeriksa redudancy dalam model.

Memeriksa kembali apakah model tersebut masih mengalami

pengulangan

o Memvalidasi model konseptual local melawan transaksi pengguna.

Dalam tahap ini dilakukan peyakinan bahwa model konseptual lokal ini

dapat memenuhi kebutuhan transaksi pengguna.

24

o Melihat kembali model konseptual data local dengan pengguna.

Dalam tahap ini model konseptual dan data lokal dilihat oleh pengguna

untuk meyakinkan bahwa model tersebut adalah gambaran yang benar

dari kebutuhan yang ada.

2. Web Data Analysis

Proses yang di-input secara online, tidak bergantung pada pertimbangan

fisiknya. Hasilnya adalah Conceptual Web Data Model yang memperlihatkan

susunan dari informasi yang ditampilkan oleh web pages.

3. Logical Database Design

Proses yang digunakan berdasarkan data model tertentu (misal :

relational) dengan merancang bagaimana data disimpan dalam database (struktur

data, organisasi file). Hasilnya adalah Logical Data Model yang dibangun dan

divalidasi dengan data model logikal lokal dan global untuk setiap kebutuhan.

Berikut ini adalah tahapan membangun desain logikal menurut Connolly

(2005, p1326 – 1328):

Tahap 2. Membangun dan memvalidasi data model logikal lokal untuk setiap

kebutuhan, dengan:

o Menghilangkan fitur yang tidak sesuai dengan model relasional

(optional).

Memperbaiki model data konseptual lokal untuk menghilangkan fitur

yang tidak sesuai dengan model relasional, tujuan tahap ini adalah untuk:

Menghilangkan tipe relasi biner “Many to Many” (*:*).

25

Menghilangkan tipe relasi rekursif “Many to Many” (*:*).

Menghilangkan tipe relasi yang komplek.

Menghilangkan atribut yang memiliki nilai lebih dari satu.

o Mengambil relasi untuk model logis data lokal.

Pada tahap ini dibuat relasi untuk model logis data lokal yang digunakan

untuk menggambarkan entitas, relasi dan atribut yang telah

diidentifikasikan. Menentukan relasi untuk model logis data lokal:

Menentukan Strong Entity.

Menentukan Weak Entity.

Membangun relasi biner “One to Many” (1:*).

Membangun relasi biner “One to One” (1:1).

o Memvalidasi relasi dengan normalisasi.

Dalam tahap ini dilakukan normalisasi untuk mengembangkan model

sehingga memenuhi aturan yang berlaku yang menghindari perulangan

data yang tidak perlu.

o Memvalidasi relasi terhadap transaksi pengguna.

Dalam tahap ini relasi dilihat apakah mendukung kebutuhan transaksi

pengguna.

o Mendefinisikan integrity constraint.

5 Tipe integrity constraints:

Required data, beberapa atribut harus selalu mengandung nilai yang

valid.

26

Attribute domain constraints, setiap atribut memiliki domain, yang

terdiri dari nilai-nilai yang dibolehkan.

Entity integrity, setiap primary key tidak boleh kosong (null).

Referential integrity, setiap foreign key dari relasi anak terhubung

pada relasi induk mengandung nilai yang sesuai dengan nilai kunci

kandidat.

Enterprise integrity, memperhatikan aturan-aturan yang diketahui

sebagai aturan perusahaan atau sering disebut aturan bisnis.

o Melihat kembali model logis data lokal dengan pengguna.

Tahap 3. Membangun dan memvalidasi model data logikal global, dengan:

o Menggabungkan model logis data lokal kedalam model global.

o Memvalidasi model logis data global.

o Mengecek perkembangan di masa mendatang.

Mengecek apakah model logis data global tersebut dapat memenuhi

kebutuhan di masa depan, memenuhi perubahan yang mungkin terjadi.

o Melihat kembali model logis data global dengan pengguna.

Mengecek kembali apakah model tersebut merupakan gambaran yang

benar dari kebutuhan.

4. Logical Web Data Design

Proses mapping antara data yang ditampilkan dalam web pages dan data

terkandung atau disimpan dalam database. Hasilnya adalah Logical Web Data

27

Model yang memperlihatkan bagaimana struktur konseptual benar benar

ditampilkan dalam web pages.

e. Physical Web Database Design

Dalam tahap ini, terdapat tahap-tahap kecil yang membantu proses

perancangan aplikasi web database, yaitu :

1. Physical Database Design

Proses menghasilkan penerapan basis data pada penyimpanan sekunder,

menggambarkan relasi dasar, organisasi file, dan indeks yang digunakan untuk

memperoleh akses yang efisien ke data, dan apapun integrity constraint dan

ukuran keamanan. Hasilnya adalah Physical Web Data Model.

Perancangan fisik basis data menurut Connolly (2005, p1326 – 1328)

meliputi:

Tahap 4. Menterjemahkan data model logikal global ke DBMS yang telah

ditentukan.

Pada tahap ini dihasilkan skema basis data relasional dari model data

logikal global yang dapat diterapkan pada DBMS.

o Mendesain relasi dasar.

Memutuskan bagaimana menggambarkan relasi dasar yang

teridentifikasikan pada model logis data global ke dalam DBMS.

Untuk setiap relasi didefinisikan: Nama relasi, Daftar atribut sederhana

dalam kurung, Primary key, foreign key, alternate key, Daftar atribut

yang dibutuhkan dan bagaimana mereka dapat dihitung, serta

28

Menentukan integrity constraints untuk setiap foreign keys yang

teridentifikasikan.

Untuk kamus data didefinisikan Domain, terdiri dari tipe data, panjang,

dan aturan dari domain, Nilai pilihan pertama yang diberikan untu setiap

atribut, serta Apakah atribut tersebut boleh mengandung null atau tidak.

o Mendesain gambaran data yang diperoleh.

Memutuskan bagaimana menggambarkan data sekarang yang ada di data

model logikal global ke dalam DBMS.

o Mendesain enterprise constraints.

Merancang batasan-batasan yang diberikan oleh perusahaan ke dalam

DBMS.

Tahap 5. Mendesain gambaran fisik

Pada tahap ini ditentukan organisasi file yang optimal untuk

menyimpan relasi dasar dan indeks yang dibutuhkan untuk memperoleh

performa yang diterima.

Salah satu tujuan perancangan fisik basis data adalah untuk menyimpan data

dalam cara yang efisien, adapun kendalanya adalah:

o Transaction throughput: jumlah transaksi dalam 1 interval waktu.

o Response time: waktu yang dibutuhkan untuk menyelesaikan satu

transaksi lengkap.

o Disk storage: jumlah kapasitas disk yang dibtukan untuk menyimpan

berkas basis data.

Hal – hal yang dilakukan pada tahap 5 ini adalah:

o Menganalisa transaksi.

29

Untuk mendesain basis data fisik secara efisien, harus dipahami

pengetahuan tentang transaksi atau queries yang akan terjadi dalam basis

data.

o Memilih organisasi file yang digunakan.

Menentukan organisasi file yang efisien untuk setiap relasi dasar. Tipe

organisasi file yang sering digunakan: Heap, Hash, Indexed sequential

access method (ISAM), B* -tree, dan Clusters

o Memilih indeks yang digunakan.

Untuk memperkirakan apakah penambahan indeks dapat meningkatkan

performa dari sistem.

o Memperkirakan besar kapasitas harddisk yang dibutuhkan.

Menghitung perkiraan kapasitas harddisk yang dibutuhkan oleh basis

data yang sesuai dengan DBMS dan perangkat keras yang dibutuhkan.

Tahap 6. Mendesain tampilan pengguna.

Pada tahap ini dilakukan perancangan tampilan pengguna yang telah

diidentifikasikan selama proses mengumpulan dan analisis tahap siklus

aplikasi hidup basis data relasional.

Tahap 7. Mendesain mekanisme keamanan.

Pada tahap ini didesain keamanan yang dibutuhkan basis data

sesuai keinginan pengguna.

Secara umum ada 2 tipe keamanan basis data, yaitu Keamanan sistem, serta

Keamanan data.

30

Tahap 8. Memperhitungkan pengulangan data terkontrol di awal.

Pada tahap ini ditentukan apakah terjadi pengulangan data dengan

menyederhanakan aturan normalisasi yang akan meningkatkan performa

sistem.

Tahap 9. Mengawasi dan merawat sistem operasi.

Pada tahap ini dilakukan pengawasan terhadap sistem operasi dan

meningkatkan performa dari sistem untuk memperbaiki desain keputusan yang

tidak sesuai atau merefleksikan perubahan kebutuhan.

2. Physical Web Data Design

Proses implementasi mekanisme dimana data mengalir diantara web

pages dan database. Umumnya, kinerja berjalan cepat dan bebas kesalahan.

Hasilnya adalah Physical Web Data Model yang memperlihatkan bagaimana

model logikal dari web pages diimplementasikan.

2.2.2 Teori AJAX

A. Pengertian JavaScript

JavaScript menurut http://en.wikipedia.org/wiki/Javascript adalah bahasa

pemrograman dinamis, weakly-typed, dan prototype-based dengan fungsi yang

sempurna.

B. Pengertian XML

Extensible Markup Language (XML) adalah bahasa markup serbaguna

yang direkomenadasikan W3C (World Wide Web Consortium) untuk

31

mendeskripsikan berbagai macam data. XML menggunakan markup tags seperti

halnya HTML namun penggunaannya tidak terbatas pada tampilan halaman web

saja (http://www.w3.org/XML).

C. Pengertian AJAX

Asynchronous JavaScript And XML, atau disingkat AJAX, adalah suatu

teknik pemrograman berbasis web untuk menciptakan aplikasi web interaktif.

Tujuannya adalah untuk memindahkan sebagian besar interaksi pada komputer

web surfer, dengan melakukan pertukaran sejumlah data dengan server di

belakang layar, sehingga halaman web tidak harus dibaca ulang secara

keseluruhan setiap kali seorang pengguna melakukan perubahan. Hal ini akan

meningkatkan interaktivitas, kecepatan, fungsionalitas, dan usability pada

halaman di web.

Menurut Nicholas, Jeremy McPeak, dan Joe Fawcett (2006, p8), Konsep

AJAX diperkenalkan oleh Jesse James Garret dari tim Adaptive Path dengan

mengeluarkan artikel berjudul ”AJAX: A New Approach to Web Applications”.

AJAX dipopulerkan pada tahun 2005 oleh Google (http://maps.google.com/)

yang dapat di-zoom (diperbesar) tanpa harus melakukan refresh dan di-render

secara seketika dan berikutnya oleh Meebo (http://www.meebo.com) melalui

aplikasi chatting yang kaya akan fitur AJAX.

D. Prinsip Pada AJAX

Sebagai sebuah model aplikasi web baru, AJAX masih berada dalam

tahap pertumbuhan. Michael Mahemoff (http://mahemoff.com/), seorang

32

pengembang software dan ahli peralatan, mengidentifikasi beberapa prinsip

kunci dari aplikasi AJAX yang baik, yaitu :

a. Lalu lintas yang minim

AJAX dapat meminimasi tingkat kepadatan lalu lintas antara client dan

server, dan tidak menerima maupun mengirimkan informasi tambahan yang

kurang penting.

b. Tidak ada kejutan

Pada aplikasi AJAX tidak menjadi masalah model interaksi pengguna apa

yang dipilih, asal konsisten saja sehingga tidak membingungkan pengguna.

c. Ketentuan yang tetap

Pengembang web tidak perlu membuang waktu untuk menemukan model

interaksi pengguna yang baru dimana pengguna mungkin bisa merasa tidak

familiar dengan model tersebut.

d. Tidak ada distraksi

Menghindari elemen yang tidak penting dan mengganggu seperti animasi

yang berulang-ulang, maupun halaman yang dapat berkedip-kedip. Hal-hal

seperti itu dapat mengecoh dan menghilangkan konsentrasi pengguna.

e. Mudah diakses

Pengembang aplikasi harus memperkirakan siapa pengguna primer maupun

sekunder dan bagaimana mereka mengakses aplikasi AJAX tersebut.

Pengembang aplikasi juga diharapkan dapat memperkirakan apakah

pengguna akan menggunakan browser lama maupun software khusus.

33

f. Menghindari download terhadap keseluruhan halaman

Pengembang aplikasi sebaiknya tidak mengacaukan aktivitas pengguna

dengan men-download sebagian kecil data pada satu tempat, namun

melakukan proses loading ulang untuk keseluruhan halaman di tempat lain.

g. User first

Pengembang aplikasi sebaiknya merancang aplikasi AJAX dengan

memikirkan penggunanya terlebih dahulu. Pengembang aplikasi sebaiknya

berusaha untuk membuat use case umum yang mudah untuk dilaksanakan.

E. Perbandingan Aplikasi Web Klasik dengan AJAX

Aplikasi web klasik kebanyakkan membuat pengguna menunggu setelah

aplikasi dijalankan, semua aplikasi akan mengambil semua data yang diperlukan

untuk nantinya ditampilkan ketika ada permintaan dari pengguna.

Secara perbandingan visual dapat dilihat dalam gambar dibawah ini :

34

Gambar 2.2 Model web klasik (kiri) dibandingkan dengan model web AJAX (kanan)

(Sumber : http://www.adaptivepath.com)

F. Teknologi Yang Berhubungan Dengan AJAX

Artikel Jesse James Garret menjelaskan beberapa teknologi yang

dilihatnya sebagai bagian dari solusi AJAX:

HTML/XHTML: bahasa representasi isi utama

CSS: menyediakan format beragam untuk XHTML

DOM: perubahan dinamis dari halaman yang di-load

XML: format pertukaran data

XSLT: mengubah XML menjadi XHTML (dibahasakan oleh CSS)

XMLHttp: perantara komunikasi yang utama

AJAX engine

user interface

browser client

user interface

server-side systems

datastore, backend processing, legacy

systems

web and/or XML server

server-side systems

datastore, backend processing, legacy

systems

web and/or XML server

classicweb application model

AJAXweb application model

http(s) transport

HTTP request HTML+CSS data

http(s) transport

HTTP request HTML+CSS data

browser client

JavaScript callHTML+CSS data

35

JavaScript: bahasa scripting yang digunakan untuk program mesin AJAX.

Pada kenyataannya, semua teknologi di atas bisa digunakan dalam solusi

AJAX, tapi hanya 3 yang harus ada, yaitu : HTML/XHTML, DOM, and

JavaScript. XHTML diperlukan untuk menampilkan informasi, sedangkan DOM

diperlukan untuk mengubah sebagian halaman XHTML tanpa perlu load lagi.

Bagian akhir yaitu Javascript, diperlukan untuk menginisialisasi komunikasi

client-server dan memanipulasi DOM untuk meng-update halaman web.

G. Cara Kerja AJAX

Aplikasi AJAX mengeliminasi sifat alamiah start-stop-start-stop pada

interaksi website dengan menggunakan AJAX engine antara pengguna dan

server. Berikut ini adalah gambaran umum cara kerja AJAX menurut Jesse

James Garrett di http://www.adaptivepath.com/ideas/essays/archives/000385.php

(2005):

1. Penambahan layer ke aplikasi sepertinya akan membuatnya kurang

responsif, namun ternyata kebalikannya.

2. Pada awal sesi, browser me-load sebuah AJAX engine yang ditulis dalam

JavaScript dan biasanya dimasukkan pada frame yang tersembunyi.

3. Engine ini bertanggungjawab pada pembuatan interface yang dilihat

pengguna dan mengkomunikasikannya dengan server.

4. AJAX engine memperbolehkan interaksi pengguna dengan aplikasi secara

asynchronous, komunikasi mandiri dengan server. Oleh karena itu,

pengguna tidak akan melihat browser window yang kosong dan icon

hourglass yang menunggu server.

36

AJAX web application model (asynchronus)

Gambar 2.3 Pola interaksi asynchronous pada aplikasi AJAX.

(Sumber : http://www.adaptivepath.com)

Inti dari pemrograman yang menggunakan AJAX adalah untuk mengatasi

kebutuhan loading halaman website yang berbasiskan media HTML atau HTTP.

AJAX semakin menegaskan pentingnya kondisi awal bagi proses evolusi dari

user interface yang bersifat kompleks, intuitif, dinamis, dan data sentris dalam

halaman di website.

H. Kelebihan dan Kekurangan AJAX

Sebagai teknologi web yang tergolong baru, banyak web developer

tertarik untuk mengembangkan AJAX. Berikut adalah keuntungan web dengan

AJAX menurut http://en.wikipedia.org/wiki/AJAX_programming:

client

time

Server side processing

server

Browser UI

AJAXEngine

User activity

Client side processing

input

display

data transmission

37

Penggunaan Bandwidth

Dengan mengeneralisasikan HTML secara lokal pada browser, serta

hanya memakai fungsi pada JavaScript dan data aktual, halaman website

yang menggunakan AJAX terlihat dapat melakukan proses loading relatif

lebih cepat karena hasil loading yang akan muncul lebih kecil ukurannya.

Pemisahan data, format, style, dan fungsi.

Programmer biasanya digerakkan oleh perkembangan yang nantinya

akan memotivasi mereka untuk mengadopsi pemisahan data atau content

mentah yang harus dikirimkan, format atau struktur halaman website, gaya

element yang ada pada halaman website, dan fungsionalitas dari halaman

website.

Di samping kelebihan yang ditawarkan, http://en.wikipedia.org/wiki/

AJAX_programming juga menjelaskan kekurangan dari penggunaan AJAX :

Integrasi Browser

Halaman website yang dirancang secara dinamis tidak terdaftar pada

mesin history browser, maka fungsi ”Back” pada browser yang berada di

pihak pengguna tidak akan memberikan hasil yang diinginkan. Kasus lainnya

adalah perubahan yang dilakukan pada halaman website dinamis

membuatnya sulit bagi pengguna untuk melakukan bookmark pada area

tertentu dari aplikasi.

Response Time

Ketika keseluruhan halaman dibuat, maka ada sejumlah kejadian

singkat yang menuntut penyesuaian pada indra penglihatan pengguna ketika

38

content berubah. Tingkat penyesuaian yang rendah pada perubahan layar

akan membuat network latency (interval yang berada diantara request oleh

pengguna dan respon dari server) semakin terlihat.

Optimisasi pada search engine

AJAX, di sisi pengguna, merupakan alternatif untuk kenyamanan

bagi pengguna, dimana browser tidak akan mengambil seluruh halaman, tapi

hanya loading bagian yang perlu diganti saja dari halaman tersebut.

Sayangnya kenyamanan ini harus dibayar cukup mahal, karena search engine

tidak akan mengenali seluruh isi dari website tersebut.

Ketergantungan pada JavaScript

AJAX bergantung pada JavaScript, dimana hal ini sering

diimplementasikan secara berbeda oleh browser yang berbeda atau versi

browser tertentu. Karena hal ini, website yang menggunakan JavaScript

mungkin butuh untuk dites pada browser yang berbeda untuk dicek

kompatibilitasnya. Masalah juga timbul jika pengguna menonaktifkan

penggunaan JavaScript pada browser, hal ini akan mematikan fungsionalitas

yang dibangun dalam halaman website.

Analitis Web

Harus diberikan perhatian dalam mengatur sebuah halaman atau

bagian tertentu pada halaman sehingga dapat dilakukan pelacakan secara

akurat. Sistem analitis akan memungkinkan pelacakan kejadian tertentu

daripada harus melihat keseluruhan halaman yang sederhana, seperti

sebagaimana click pada tombol atau link tertentu, adalah sesuatu yang dapat

diakomodasikan oleh website yang menggunakan AJAX.

39

2.2.3 Teori Unified Modeling Language (UML)

Menurut Bahrami (1999, p92) “ The unified modeling language is language

for specifying, constructing, visualizing, and documenting the software system and

its components. The UML is a graphical language with sets of rules and semantics.”,

yang artinya Unified Model Language adalah bahasa untuk memspesifikasikan,

membangun, memperlihatkan, dan mendokumentasikan suatu sistem perangkat

lunak beserta komponen-komponennya. UML adalah suatu bahasa grafikal dengan

seperangkat aturan dan semantic.

Tujuan utama dalam mendesain UML adalah:

1. Mempersiapkan gambaran bahasa pemodelan bagi pengguna agar dapat

mengembangkan dan menukar dengan model yang lebih berguna.

2. Menyediakan ekstensibilitas dan mekanisme khusus untuk memperluas konsep

inti.

3. Membuat suatu keterangan bahasa pemograman dapat berdiri sendiri dan

mengembangkan proses.

4. Mempersiapkan suatu basis formal agar dapat memahami bahasa pemodelan.

5. Mendorong pertumbuhan pemasaran alat Object Oriented.

6. Mendukung konsep pengembangan ke tingkat yang lebih tinggi.

7. Menggabungkan latihan dan metode terbaik.

Setiap model dapat diekspresikan pada level ketentuan yang berbeda. Model

yang terbaik akan dihubungkan pada realitas. UML mendefinisikan sembilan

diagram grafikal ,yaitu :

1. Class diagram

40

UML class diagram dapat disebut juga sebagai object modeling, yang

merupakan diagram analisa utama yang statis. Class diagram merupakan gabungan

dari elemen model statik, seperti class dan hubungannya, dihubungkan dalam

sebuah grafik satu sama lain beserta isinya.

Menurut Fowler(2000, p49) dan Larman(2005, p249-p256), ada tiga perspektif

yang dapat dipakai untuk membangun class diagram, yaitu :

a. Konseptual atau essential

Diagram merepresentasikan konsep dari domain pembelajaran. Konsep ini

secara alamiah menghubungkan ke class-class yang mengimplementasikan konsep

real-world. Model konseptual seharusnya dibuat dengan sedikit atau bahkan tidak

berkaitan dengan software yang mungkin mengimplementasikannya, sehingga dapat

dikategorikan sebagai language-independent.

b. Specification

Diagram specification lebih memperlihatkan kepada interface software, bukan

pada implementasinya. Perlu diingat bahwa kunci efektivitas pemrograman object-

oriented adalah untuk memprogram interface class, bukan implementasinya.

c. Implementasi

Dalam sudut pandang ini, pengembang memiliki class-class, dan

mendasarkannya pada implementasi sederhana. Perspektif ini paling sering

digunakan, namun dalam berbagai hal perspektif specification adalah perspektif

yang lebih baik untuk diikuti.

Panduan dalam membangun class diagram, menurut Fowler(2000, p49) dan

Larman(2005, p249-p256), adalah sebagai berikut :

a. Menentukan konsep

41

Konsep adalah sebuah ide, sebuah benda, atau sebuah obyek. Konsep juga

dapat dikategorikan sebagai: symbol (kata kata atau image yang merepresentasikan

konsep), intension (definisi konsep), dan extension (sekumpulan contoh dimana

konsep diletakkan).

b. Menentukan object diagram ( class )

Object diagram (class) adalah snapshot dari objek sistem pada suatu waktu.

Objek merupakan bentuk nyata dari suatu class, dengan kata lain objek adalah

instance dari class. Class adalah sebuah spesifikasi yang jika diinstansiasi akan

menghasilkan sebuah objek dan merupakan inti dari pengembangan dan desain

berorientasi objek. Class menggambarkan keadaan (atribut/properti) suatu sistem,

sekaligus menawarkan layanan untuk memanipulasi keadaan tersebut

(metode/fungsi). Penulisan nama objek diawali dengan huruf kecil. Class, atribut,

dan metode atau operations dapat dinotasikan seperti di bawah ini :

<<Nama Class >>

<<Atribut >>

<<Metode / Operations>>Gambar 2.4 Notasi Class, atribut, dan metode atau operations

42

c. Menentukan asosiasi

Sebuah link mewakili hubungan antar dua objek. Asosiasi merepresentasikan

hubungan antara class, dan mewakili kelompok links. Setiap asosiasi memiliki dua

asosiasi ends, setiap end berkaitan dengan salah satu class dalam asosiasi. Asosiasi

biasanya juga memiliki multiplicity yang mengindikasikan batasan atas dan bawah

bagi obyek yang berpartisipasi. Sejumlah anak panah pada garis asosiasi

mengindikasikan adanya kemampuan untuk menavigasi. Hubungan asosiasi

ditunjukkan dengan notasi :

Gambar 2.5 Notasi Asosiasi dan Multiplicity

Terdapat empat macam jenis multiplicity pada asosiasi, yaitu :

0 : nol.

1 : satu.

1...* : 1 atau banyak.

1..2, 10..* : satu, dua, sepuluh, dan seluruh kemungkinan di atas sepuluh, namun

tidak termasuk urutan angka tiga sampai dengan sembilan.

d. Menentukan multiple dan dynamic classification

Classification merepresentasikan relationship antara obyek dan tipenya. Single

classification mengindikasikan sebuah obyek yang termasuk dalam tipe single,

dimana dapat mewarisi super-tipenya. Dalam multiple classification, sebuah obyek

dapat dideksripsikan oleh beberapa tipe yang tidak dihubungkan oleh inheritance.

Dynamic classification didefinisikan sebagai rangkaian pesan yang di-passing dari

a..b c..d

43

satu class kepada class lainnya. Hubungan ini lebih lanjut dapat digambarkan

dengan menggunakan sequence diagram.

e. Menentukan agregasi dan komposisi

Komposisi adalah penamaan relationship, dimana bagian dari obyek mungkin

menjadi bagian obyek lain. Sedangkan agregasi adalah penamaan relationship,

dimana suatu obyek memberikan kontribusi bagi keberadaan obyek yang lainnya.

Hubungan agregasi ditunjukkan dengan notasi :

Gambar 2.6 Notasi Link Agregasi dan Komposisi

f. Menentukan atribut

Atribut adalah nilai data logis dari sebuah obyek. Atribut hampir sama dengan

asosiasi. Bergantung pada detil pada diagram, notasi untuk atribut dapat

menunjukkan nama atribut, tipe atribut, dan nilai default-nya.

g. Menentukan operations

Operations adalah proses-proses yang dilakukan oleh class. Operations, secara

jelas, berkorespondensi dengan metode pada class. Pada tingkat specification,

operations berkorespondensi pada metode public dari sebuah tipe. Pada model

implementation, operations dapat bersifat private dan protected.

h. Menentukan generalization

Dalam model specification, generalization berarti bahwa interface dari subtype

harus mengandung semua elemen dari interface-nya. Interface dari subtype

dikatakan untuk dicocokkan dengan interface supertype. Generalization pada

a..b c..da..b c..d

44

perpektif implementation dihubungkan dengan inheritance pada bahasa

pemrograman. Hubungan generalisasi dinotasikan seperti di bawah ini :

Gambar 2.7 Notasi Link Generalization

i. Menentukan constraint rules

Bentuk dasar dari associations, atribut, dan generalization adalah untuk

menspesifikasikan constraints penting, namun tidak dapat mengindikasikan setiap

constraints. Constraints tersebut perlu untuk ditangkap melalui class diagram.

2. Use case diagram

Use case mendefinisikan apa yang terjadi di dalam sistem ketika use case

dilakukan. Model use case menampilkan ”aktor” dan sistem yang sedang

berlangsung. Use case menampilkan kegiatan yang sedang berjalan di dalam sistem.

Tahapan pembuatan Use case, menurut Fowler(2000, p39), Schneider(2001,

p11), dan Larman(2005, p61-p64), adalah sebagai berikut:

a. Mengidentifikasi aktor atau external entity

Aktor adalah semua yang berhubungan dengan sistem aplikasi, contohnya adalah

manusia, software, hardware, media, penyimpan data, maupun network. Setiap aktor

memiliki peranan tertentu. Namun mereka bersifat eksternal, karena tidak berada di

dalam sistem. Notasi untuk aktor digambarkan seperti di bawah ini :

45

atau Aktor

Gambar 2.8 Notasi Aktor

b. Mengidentifikasi use case

Use case adalah perilaku sistem yang memproduksi atau menghasilkan hasil

atau nilai tertentu bagi aktor. Use case mendeskripsikan hal-hal yang diinginkan

aktor untuk dilakukan sistem. Sebuah use case diagram dapat terdiri dari banyak use

case. Notasi untuk use case digambarkan seperti di bawah ini :

Gambar 2.9 Notasi Use Case

c. Mengidentifikasi system boundaries

Pada dasarnya system boundaries adalah sistem yang di dalamnya terkandung

kumpulan use case, dan di luar sistem adalah kumpulan external entity. Notasi untuk

system boundaries digambarkan seperti di bawah ini :

Gambar 2.10 Notasi System Boundaries

d. Mengidentifikasi use case relationship

Use case relationship adalah ringkasan mengenai hubungan antara aktor dan

use case-nya. Notasi untuk relationship digambarkan seperti di bawah ini :

<< Aktor >>Aktor

Use case

Use Case Group

46

Gambar 2.11 Notasi Link Use case Relationship

Terdapat tiga jenis use case relationship :

a. Include relationship

Terjadi ketika pengguna memiliki sebuah tingkah laku yang mirip terhadap

lebih dari satu use case, dan pengembang aplikasi ingin menghindari

pengulangan. Notasi untuk include relationship digambarkan seperti di

bawah ini :

Gambar 2.12 Notasi Include relationship

b. Generalization relationship

Ketika pengembang aplikasi memiliki sebuah use case yang mirip dengan

use case lain, dan memungkinkan untuk terjadinya alternative scenario

yang lain dengan tujuan akhirnya tetap sama. Notasi untuk generalization

relationship digambarkan seperti di bawah ini :

Gambar 2.13 Notasi Generalization relationship

c. Extend relationship

Use case tambahan dapat menambahkan sifat atau perilaku tertentu ke

dalam use case induk, namun dengan catatan, pada use case induk harus

47

ditambahkan atau dideklarasikan “point tambahan”. Notasi untuk extend

relationship digambarkan seperti di bawah ini :

Gambar 2.14 Notasi Extend relationship

e. Menentukan apakah use case tersebut merupakan use case bisnis atau use case

system

Sistem use case menyangkut interaksi use case dengan software. Sedangkan

use case bisnis membahas mengenai bagaimana bisnis merespons seorang customer

maupun sebuah event.

f. Membuat use case secara expanded

Expanded use case adalah use case dengan tingkat detil tinggi, dimana hal ini

membantu pemahaman terhadap proses dan kebutuhan sistem. Format atau struktur

berikut ditempatkan di bagian awal deskripsi use case:

Use Case : diisi dengan nama use case.

Actor : diisi dengan nama actor atau external entity yang bersesuaian.

Purpose : diisi dengan tujuan utama use case.

Overview : diisi dengan ulasan atau ringkasan singkat use case.

Type : diisi dengan tipe use case yang digunakan.

Cross References : diisi dengan use case yang bersesuaian dan fungsi sistem.

48

3. Behaviour diagram

a. Interaction diagram

Interaction diagram menampilkan beberapa contoh obyek dan

menyampaikan pesan antara obyek-obyek dan use case. Ada 2 jenis

interaction model :

Sequence Diagram

Sequence diagram menampilkan interaksi yang tersusun menurut

waktu kejadian. Sequence diagram menampilkan partisipasi obyek dalam

interaksi dengan garis penghubung dan pesan, tersusun sesuai waktu

kejadian.

Tahapan dalam menyusun sequence diagram, menurut

Fowler(2000, p68) dan Larman(2005, p173-p177) :

a. Menentukan obyek

Obyek ditunjukkan sebagai sebuah kotak di atas garis vertikal.

Notasi untuk obyek digambarkan seperti di bawah ini :

Gambar 2.15 Notasi Obyek

b. Membuat lifeline obyek

Lifeline object merepresentasikan garis hidup obyek selama

interaksi sistem. Bagian dari lifeline object biasanya digambarkan dengan

garis putus-putus untuk mengindikasikan bagian dari kehidupan obyek

sedang tidak terlibat dalam situasi yang digambarkan di diagram. Notasi

untuk lifeline object digambarkan seperti di bawah ini :

Object:Class

49

Gambar 2.16 Notasi Lifeline Object dan Focus Of Control

c. Mendefinisikan message, system events, system operation, dan

system boundaries

Message direpresentasikan dengan sebuah anak panah di antara

dua lifeline obyek. System events adalah input eksternal yang

diciptakan oleh aktor kepada sebuah sistem. Sebuah event

menginisiasikan operasi yang merespon sistem. System operation adalah

sebuah operasi sistem yang mengeksekusi hasil respon kepada sebuah

sistem event. System boundaries secara umum dijabarkan sebagai

software, atau kemungkinan hardware bagi sistem tersebut, yang

membatasi interaksi aktor dengan sistem. Notasi untuk message

digambarkan seperti di bawah ini :

Gambar 2.17 Notasi Message

Notasi untuk procedure call digambarkan seperti di bawah ini :

Gambar 2.18 Notasi Procedure Call

procedure call ( )

event

Object:Class

Lifeline Object

Focus Of Control

50

Untuk memaparkan tipe dan jenis message dengan lebih jelas, dapat

dilihat pada tabel di bawah ini :

Tabel 2.1 Tabel Tipe dan jenis Message

Message Tipe flow kind : flat;

Message(call) Tipe flow kind : procedure call

Message Message yang ditujukan untuk object

itu sendiri

Return Message yang mengembalikan suatu

nilai

Message yang mengembalikan suatu

nilai untuk dirinya sendiri

d. Membuat activation box

Hal ini dilakukan untuk menunjukkan kapankah sebuah obyek akan aktif,

atau prosedurnya sedang berada dalam stack. Ada dua informasi

pengontrol yang biasa digunakan, yaitu :

Condition, yang mengindikasikan ketika message dikirim, hanya

jika kondisinya terpenuhi.

Iteration maker, dimana hal ini menunjukkan message dikirim

beberapa kali ke banyak obyek penerima.

51

e. Mendefinisikan adanya return

Return mengindikasikan proses kembalinya dari sebuah message,

namun tidak menghasilkan message baru. Notasi untuk return

digambarkan seperti di bawah ini.

Gambar 2.19 Notasi Return

Notasi untuk recursive call digambarkan seperti di bawah ini.

Gambar 2.20 Notasi Recursive Call

Collaboration Diagram

Collaboration diagram menampilkan sebuah kolaborasi yang merupakan

gabungan dari obyek-obyek yang terhubung dalam konteks partikular dan

interaksi yang merupakan gabungan dari pesan-pesan di antara obyek dalam

kolaborasi untuk mencapai tujuan akhir.

Tahapan membuat collaboration diagram, menurut Fowler(2000, p72)

dan Larman(2005, p249-p256) :

Object:Class

Recursive Call

52

a. Buatlah diagram terpisah untuk setiap operasi sistem.

Untuk setiap message sistem operasi, buatlah sebuah diagram dengan

menempatkannya sebagai starting message. Jika diagram menjadi kompleks,

pecahlah menjadi diagram-diagram yang lebih kecil.

b. Mendefinisikan class dan instances.

Pada collaboration diagram, obyek pada sequence diagram dapat

disebut sebagai icon. Tetap menggunakan class box untuk merepresentasikan

instance dari class, namun namanya harus menggunakan garis bawah, dan

untuk nama class harus didahului oleh sebuah titik dua. Notasi untuk class

digambarkan seperti di bawah ini :

Gambar 2.21 Notasi Class dan Instances

c. Mendefinisikan message

Message pada collaboration diagram mengindikasikan hubungan

antara dua instance, bentuk navigasi dan bentuk visibility antara instance.

Seperti pada sequence diagram, anak panah mengindikasikan message yang

dikirimkan, namun pada collaboration diagram, sequence-nya diindikasikan

dengan memberikan penomoran pada message. Notasi untuk message

digambarkan seperti di bawah ini :

Gambar 2.22 Notasi Message

Object 1 Object 21: Message 1

Object:Class

53

b. Statechart Diagram

Statechart diagram atau biasa disebut juga state diagram menampilkan

rangkaian dari bagian dimana obyek selalu berjalan dalam merespon untuk

stimulasi luar dan pesan-pesan.State diagram merepresentasikan bagian dari

metode eksekusi, dan aktifitas diagram yang menggambarkan aktifitas obyek

dan menampilkan metodenya.

Tahapan membuat statechart diagram, menurut Fowler(2000, p119)

dan Larman(2005, p485-p492) :

a. Menentukan event

Event adalah kejadian yang signifikan dan perlu diperhatikan.

b. Menentukan state atau activity

State adalah kondisi dari obyek pada saat tertentu, atau waktu antara

events. State ditunjukkan dengan bentuk oval. Notasi untuk state

digambarkan seperti di bawah ini.

Gambar 2.23 Notasi State

c. Menentukan transition atau action

Transition adalah relationship antara dua state yang mengindikasikan

bahwa ketika sebuah event terjadi, maka obyek akan bergerak dari state

terdahulu ke state berikutnya. Transition ditunjukkan dalam bentuk anak

Initial State

Final StateState State 3

State 2

State 1

Nested state

54

panah, diberi label sesuai event-nya. Notasi untuk transition digambarkan

seperti di bawah ini :

Gambar 2.24 Notasi Link Transition atau Action

d. Mendefinisikan guard

Guard adalah kondisi logis yang akan mengembalikan nilai “ true” atau

“false”.

e. Menentukan initial pseudo-state.

Initial pseudo-state adalah awal transisi chart, yang nantinya akan bergerak

atau bertransisi ke state lain ketika instance dibentuk.

c. Activity Diagram

Activity diagram merupakan variasi atau kasus spesial dari penerapan

mesin, yang dalam penerapannya aktifitas menampilkan operasi dan transisi

yang berjalan cepat dengan penyelesaian dari operasi tersebut. Tujuan utama

dari activity diagram adalah untuk membentuk suatu perjalanan dan proses

apa saja yang terjadi dalam use case atau diantara beberapa class.

Tahapan membuat activity diagram menurut Fowler(2000, p129) yaitu :

a. Menentukan activity state

Activity state adalah state yang mengindikasikan kejadian tertentu, baik

proses pada real-world, atau eksekusi dari tugas rutin sebuah software.

Notasi activity state digambarkan seperti di bawah ini :

Event ( atribut ) [ kondisi ]

55

Gambar 2.25 Notasi Activity

b. Menentukan perilaku conditional. Perilaku conditional ditandai dengan:

Branch yang memiliki sebuah transisi masukan dan beberapa

transisi keluaran yang tervalidasi. Notasi branch digambarkan seperti di

bawah ini :

Gambar 2.26 Notasi Branch

Merge memiliki transisi masukan yang banyak, dan sebuah

output. Notasi Merge digambarkan seperti di bawah ini :

Gambar 2..27 Notasi Merge

c. Menentukan perilaku parallel (synchronization bar)

Fork memiliki sebuah transisi masukan dan beberapa transisi

keluaran. Ketika transisi masukan diterima, semua transisi keluaran

dilakukan secara parallel. Notasi fork digambarkan seperti di bawah ini:

Gambar 2.28 Notasi Fork

Joins, yang mensinkronisasi perilaku paralel akibat diterapkannya

fork. Dengan joins, transisi keluaran hanya dilakukan ketika semua

Start Activity

Final Activity / EndActivity

56

state pada transisi masukan telah selesai melakukan aktivitas mereka.

Apabila diterapakan dengan fork, maka harus menerapkan join yang

melengkapi fork. Notasi joins digambarkan seperti di bawah ini :

Gambar 2.29 Notasi Joins

d. Menentukan dynamic concurrency

Dynamic concurrency memperbolehkan pengembang untuk

menunjukkan iterasi tanpa harus membangun sebuah loop.

e. Menentukan swimlanes

Dengan adanya swimlanes, maka dapat disertakan aktor yang

melakukan setiap aktivitasnya. Hal ini bermanfaat untuk menghindari

kompleksitas apabila mengkombinasikan beberapa logika dari activity

diagram dengan tanggung jawab dari interaction diagram.

d. Implementation diagram

Implementation diagram menampilkan fase dari pengembangan sistem,

seperti struktur dari source code dan struktur pelaksanaan waktu berjalan.

Ada dua tipe dari diagram pelaksanaan :

Component Diagram

Diagram komponen merupakan komponen fisik (seperti source code,

menjalankan program, dan tampilan pengguna) dalam desain. Komponen

diagram merupakan grafik dari komponen desain yang dihubungkan

dengan hubungan saling ketergantungan.

57

Deployment Diagram

Menampilkan konfigurasi dari proses elemen terhadapa waktu yang

sedang berjalan dan komponen software, proses dan obyek-obyek apa

saja yang terlibat di dalamnya.

Penyebaran diagram adalah sebuah grafik dari node-node yang terhubung

oleh kumpulan komunikasi. Nodes dapat berisi komponen kejadian, yang

menjelaskan kehidupan dari komponen atau perjalanan node tersebut.

Komponen dapat berisi obyek , dan dihubungkan dengan komponen lain

oleh panah penghubung ketergantungan. Setiap node atau proses elemen

dalam sistem ditampilkan dengan menggunakan kotak tiga dimensi.

Hubungan antara nodes dihubungkan dengan menggunakan garis

penghubung.

2.2.4 Teori Web Server

Menurut Hiquet(2002, p5-p20), sebuah web server adalah aplikasi yang

menerima, memproses, dan memberikan respon terhadap permintaan atau

request HTTP. Permintaan ini dikirimkan melalui web browser yang digunakan

oleh client untuk berkomunikasi, mengirimkan dan menerima informasi dari

internet. Hubungan antara web server dan web-client sering juga disebut dengan

hubungan client/server.

Menurut Whitten (2004, p531), web server adalah sebuah server tempat

meletakkan ( host ) internet ataupun intranet.