BAB II LANDASAN TEORI

(1)

2.1 Rekayasa Perangkat Lunak

Istilah Rekayasa Perangkat Lunak (RPL) secara umum disepakati sebagai

terjemahan dari istilah Software Engineering. Istilah Software Engineering

dipopulerkan tahun 1968 pada Software Engineering Conference yang

diselenggarakan oleh NATO. Sebagian orang mengartikan RPL hanya sebatas

pada bagaimana membuat program komputer. Padahal ada perbedaan yang

mendasar antara perangkat lunak (software) dan program komputer.

Perangkat lunak adalah seluruh perintah yang digunakan untuk memproses

informasi. Perangkat lunak dapat berupa program atau prosedur. Program adalah

kumpulan perintah yang dimengerti oleh komputer sedangkan prosedur adalah

perintah yang dibutuhkan oleh pengguna dalam memproses informasi (O’Brien,

1999). Pengertian RPL sendiri adalah sebagai berikut: Suatu di siplin Ilmu yang

membahas semua aspek produksi perangkat lunak, mulai dari tahap awal yaitu

analisa kebutuhan pengguna, menentukan spesifikasi dari kebutuhan pengguna,

disain, pengkodean, pengujian sampai memelihara system setelah di gunakan.

Jelaslah bahwa RPL tidak hanya berhubungan dengan cara pembuatan

program komputer. Pernyataan “semua aspek produksi” pada pengertian di atas,

mempunyai arti semua hal yang berhubungan dengan proses produksi seperti

manajemen proyek, penentuan personil, anggaran biaya, metode, jadwal, kualitas

sampai dengan pelatihan pengguna merupakan bagian dari RPL.

Pada rekayasa perangkat lunak, banyak model yang telah dikembangkan

untuk membantu proses pengembangan perangkat lunak. Model-model ini pada

umumnya mengacu pada model proses pengembangan sistem yang disebut System

Development Life Cycle (SDLC) seperti terlihat pada Gambar 2.1.

(2)

Gambar 2.1 Sistem Development Life Cycle

Setiap model yang dikembangkan mempunyai karakteristik sendiri-

sendiri. Namun secara umum ada persamaan dari model-model ini, yaitu:

• Kebutuhan terhadap definisi masalah yang jelas. Input utama dari

setiap model pengembangan perangkat lunak adalah pendefinisian masalah

yang jelas. Semakin jelas akan semakin baik karena akan memudahkan

dalam penyelesaian masalah. Oleh karena itu pemahaman masalah

seperti dijelaskan pada Bab 1, merupakan bagian penting dari

model pengembangan perangkat lunak.

• Tahapan-tahapan pengembangan yang teratur. Meskipun

model-model pengembangan perangkat lunak memiliki pola yang

berbeda-beda, biasanya model-model tersebut mengikuti pola umum analysis –

design – coding – testing - maintenance.

• Stakeholder berperan sangat penting dalam keseluruhan

tahapan pengembangan. Stakeholder dalam rekayasa perangkat lunak

dapat berupa pengguna pemilik, pengembang, pemrogram dan orang-orang

yang terlibat dalam rekayasa perangkat lunak tersebut.

• Dokumentasi merupakan bagian penting dari pengembangan

perangka lunak. Masing-masing tahapan dalam model biasanya

menghasilkan sejumlah tulisan, diagram, gambar atau bentuk-bentuk lain

yang harus didokumentasi dan merupakan bagian tak terpisahkan dari

perangkat lunak yang dihasilkan.

(3)

Keluaran dari proses pengembangan perangkat lunak harus bernilah

ekonomis. Nilai dari sebuah perangkat lunak sebenarnya agak susah di-

rupiah-kan Namun efek dari penggunaan perangkat lunak yang telah dikembangrupiah-kan

haruslah memberi nilai tambah bagi organisasi. Hal ini dapat berupa penurunan

biaya operasi, efisiensi penggunaan sumberdaya, peningkatan keuntungan

organisasi, peningkatan “image” organisasi dan lain-lain

Ada banyak model pengembangan perangkat lunak. Pengembangan

perangkat lunak dalam skripsi ini menggunakan model waterfall atau bisa disebut

sekuensial linier untuk rekayasa perangkat lunak ditunjukkan seperti gambar 2.2.

Gambar 2.2 Model Waterfall

Rekayasa dan Pemodelan Sistem Analisa Kebutuhan Desain Pengkodean Pengujian Pemeliharaan

Karena Waterfall menggunakan pendekatan perkembangan perangkat lunak

yang sistematik dan sekuensial yang mulai pada tingkat dan kemajuan sistem pada

seluruh analisis, desain, kode, pengujian, dan pemeliharaan. Dengan model ini

dilakukan aktivitas-aktivitas sebagai berikut :

Rekayasa dan pemodelan sistem/informasi:

Karena perangkat lunak selalu merupakan bagian dari sebuah sistem yang

lebih besar, pengerjaan dimulai dengan membangun syarat dari semua elemen

sistem dan mengalokasikan beberapa subset dari kebutuhan ke perangkat lunak

(4)

tersebut. Pandangan sistem ini penting ketika perangkat lunak harus berhubungan

dengan elemen-elemen lain seperti perangkat lunak, manusia, dan basis data.

Rekayasa dan analisis sistem menyangkut pengumpulan kebutuhan pada tingkat

sistem dengan sejumlah kecil analisis serta desain tingkat puncak. Rekayasa

informasi mencangkup juga pengumpulan kebutuhan pada tingkat bisnis stategis

dan tingkat area bisnis.

Analisis kebutuhan perangkat lunak :

Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khususnya

pada perangkat lunak. Untuk memahami sifat program yang dibangun, analis

harus memahami domain informasi, tingkah laku, unjuk kerja, dan antar muka

yang diperlukan. Kebutuhan baik untuk sistem maupun perangkat lunak

didokumentasikan.

Desain:

Desain perangkat lunak ini merupakan proses multi langkah yang berfokus

pada empat atribut sebuah program yang berbeda: stuktur data, arsitektur

perangkat lunak, representasi interface, dan detail (algoritma) prosedural. Proses

desain ini menterjemahkan syarat/ kebutuhan ke dalam sebuah representasi

perangkat lunak yang dapat diperkirakan demi kualitas sebelum pemunculan

kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian

dari konfigurasi perangkat lunak.

Generasi Kode:

Desain harus bisa diterjemahkan ke dalam mesin yang bisa dibaca, maka

dilakukan langkah pembuatan kode. Jika desain dilakukan dengan cara lengkap,

pembuatan kode dapat diselesaikan secara mekanis.

Pengujian:

Setelah pembuatan kode, maka dilakukan pengujian. Proses pengujian

berfokus pada logika internal perangkat lunak, memastikan bahwa semua

pernyataan sudah diuji, dan pada eksternal fungsional yaitu mengarahkan

(5)

pengujian untuk menemukan kesalahan-kesalahan dan memastikan bahwa input

dibatasi akan memberikan hasil aktual yang sesuai dengan hasil yang dibutuhkan.

Pemeliharaan:

Perangkat lunak akan mengalami perubahan setelah disampaikan kepada

pengguna. Perubahan akan terjadi karena kesalahan-kesalahan ditentukan, karena

perangkat lunak harus disesuaikan untuk mengakomodasi perubahan- perubahan

di dalam lingkungan eksternalnya (contohnya perubahan yang dibutuhkan sebagai

akibat dari perangkat periperal atau sistem operasi yang baru), atau karena

pelanggan membutuhkan perkembangan fungsional atau unjuk kerja.

Pemeliharaan perangkat lunak mengaplikasikan lagi setiap fase program

sebelumnya dan tidak membuat yang baru lagi

2.2 UML (UNIFIED MODELING LANGUAGE)

UML singkatan dari Unified Modeling Language yang berarti bahasa

pemodelan standar. (Chonoles, 2003: bab 1) mengatakan sebagai bahasa, berarti

UML memiliki sintaks dan semantik. Ketika kita membuat model menggunakan

konsep UML ada aturan-aturan yang harus diikuti. Bagaimana elemen pada

model-model yang kita buat berhubungan satu dengan lainnya harus mengikuti

standar yang ada. UML bukan hanya sekedar diagram, tetapi juga menceritakan

konteksnya.

UML diaplikasikan untuk maksud tertentu, biasanya antara lain untuk:

1. Merancang perangkat lunak.

2. Sarana komunikasi antara perangkat lunak dan proses bisnis.

3. Menjabarkan sistem secara rinci untuk analisa dan mencari apa yang

diperlukan sistem.

4. Mendokumentasikan sistem yang ada, proses-proses dan organisasinya.

UML telah diaplikasikan dalam bidang investasi perbankan, lembaga

kesehatan, departemen pertahanan, sistem terdistribusi, sistem pendukung alat

kerja, retail, sales dan supplier.

(6)

Blok pembangunan UML adalah diagram. Beberapa diagram ada yang rinci

(jenis timing diagram) dan lainnya ada yang bersifat umum (misalnya diagram

kelas). Para pengembang sistem berorientasi objek menggunakan menggunakan

bahasa model untuk menggambarkan, membangun dan mendokumentasikan

sistem yang mereka rancang. UML memungkinkan para anggota team untuk

bekerja sama dalam mengaplikasikan beragam sistem. Intinya, UML merupakan

alat konunikasi yang konsisten dalam mensuport para pengembang sistem saat ini.

Sebagai perancang sistem, mau tidak mau pasti akan menjumpai UML, baik kita

sendiri yang membuat atau sekedar membaca diagram UML buatan orang lain

(Pilone, 2005: bab 1).

Tabel 2.1 Tipe Diagram UML

Diagram

Tujuan

Keterangan

Acivity

Perilaku prosedural dan paralel

Sudah ada di UML 1

Class

Class, Fitur dan relasinya

Sudah ada di UML 1

Communication

Interaksi diantara obyek, lebih

menekankan ke link

Di UML 1 disebut

Collaboration

Component

Struktur dan koneksi dari

komponen

Sudah ada di UML 1

Composite

Structure

Dekomposisi sebuah class saat

runtime

Baru untuk UML 2

Deployment

Penyebaran / Installasi ke klien

Sudah ada di UML 1

Interaction

Overview

Gabungan antara activity dan

sequance diagram

Baru untuk UML 2

Object

Contoh konfigurasi instance

Tidak resmi ada di UML

1 Package

Struktur hierarki saat kompilasi

Tidak resmi ada di UML

1 Sequence

Interaksi antar obyek. Lebih

menekankan pada urutan

Sudah ada di UML 1

State Machine

Bagaimana event mengubah

sebuah obyek

(7)

Diagram

Tujuan

Keterangan

Timing

Interaksi antar obyek. Lebih

menekankan pada waktu

Sudah ada di UML 2

Use Case

Bagaimana user berinteraksi

dengan sebuah sistem

Sudah ada di UML 1

Pada skripsi ini hanya menggunakan use case, activity diagram, class

digram, dan sequence diagram

2.2.1 USE CASE

Menurut (Pilone, 2005:bab 7.1) use case menggambarkan fungsi tertentu

dalam suatu sistem berupa komponen, kejadian atau kelas. Sedangkan (Whitten,

2004: 258) mengartikan use case sebagai urutan langkah-langkah yang secara

tindakan saling terkait (scenario), baik terotomatisasi maupun secara manual,

untuk tujuan melengkapi satu tugas bisnis tunggal. Use case bekerja dengan cara

mendeskripsikan tipikal interaksi antara user sebuah sistem dengan sistemnya

sendiri melalui sebuah cerita bagaimana sebuah sistem dipakai. Urutan

langkah-langkah yang menerangkan antara pengguna dan sistem disebut skenario. Setiap

skenario mendeskripsikan urutan kejadian. Setiap urutan diinisialisasi oleh orang,

sistem yang lain, perangkat keras atau urutan waktu. Dengan demikian secara

singkat bisa dikatakan use case adalah serangkaian skenario yang digabungkan

bersama-sama oleh tujuan umum pengguna.

Dalam perbincangan tentang use case, penngguna biasanya disebut dengan

aktor. Aktor adalah sebuah peran yang bisa dimainkan oleh pengguna dalam

interaksinya dengan sistem.

Model use case adalah bagian dari requirement model (Jacobson et all,

1992). Termasuk disini adalah problem domain object model dan penjelasan

tentang user interface. Use case memberikan spesifikasi fungsi-fungsi yang

ditawarkan oleh sistem dari prespektif user.

(8)

Diagram use case menunjukkan 3 aspek dari sistem yaitu: actor, use case

dan sistem/ subsistem boundary. Actor mewakili peran orang, sistem yang lain

atau alat ketika berkomunikasi dengan use case. Gambar 2.1 mengilustrasikan

actor, use case dan boundary.

Gambar 2.3 Use case Model

2.2.2 ACTIVITY DIAGRAM

Activity diagram adalah teknik untuk mendeskripsikan logika prosedural,

proses bisnis dan aliran kerja dalam banyak kasus. Activity diagram mempunyai

peran seperti halnya flowchart, akan tetapi perbedaannya dengan flowchart adalah

Activity diagram bisa mendukung perilaku paralel sedangkan flowchart tidak bisa.

Activity merupakan kumpulan aksi-aksi. Aksi-aksi melakukan langkah

sekali saja tidak boleh dipecah menjadi beberapa langkah lagi. Contoh aksi yaitu:

1. Fungsi matematika

2. Pemangggilan perilaku

3. Pemrosesan data

Ketika kita menggunakan diagram aktivitas untuk memodelkan perilaku

satu classifier, classifier dikatakan kontek dari aktivitas. Aktivitas dapat

mengkases atribut dan operasi classifier, tiap objek yang terhubung dan

parameter-parameter jika aktivitas memiliki hubunganj dengan perilaku. Ketika

digunakan untuk model proses bisnis, informasi itu biasanya disebut

process-relevant data. Aktivitas diharapkan dapat digunakan ulang dalam suatu aplikasi,

sedangkan aksi biasanya spesifik dan digunakan hanya untuk aktivitas tertentu

(Sumber: Prabowo Pudjo Widodo, Herlawati, 2011)

Sistem

Use Case

Actor Actor

(9)

Berikut adalah simbol-simbol yang sering digunakan pada saat pembuatan

Activity diagram diagram aktivitas.

Tabel 2.2 Simbol simbol yang sering dipakai pada Activity diagram [Sumber:

Munawar 2005]

Simbol Keterangan

Titik awal

Titik akhir

Activity

Pilihan untuk pengambilan keputusan

Fork; digunakan untuk menunjukkan kegiatan kegiatan yang dilakukan secara paralel atau untuk menggabungkan dua kegiatan paralel menjadi satu.

Rake; menunjukkan adanya dekomposisi

Tanda waktu

Tanda pengiriman

(10)

Simbol Keterangan

Aliran akhir (Flow Final)

Contoh sederhana Activity diagram bisa dilihat pada gambar 2.4. Gambar

tersebut menjelaskan tentang aliran saat proses penerimaan order.

Dari gambar 2.4 terlihat bahwa pengisian order dan pengiriman invoice

terjadi secara paralel. Intinya tidak jadi masalah mengenai mana yang terlebih

dahulu harus diselesaikan.

Kondisi paralel jelas membutuhkan sinkronisasi. Pada kasus diatas, order

tidak akan ditutup sampai barang dikirim atau dibayar. Untuk menunjukkan hal

tersebut bisa digunakan join sebelumnya action close order. Dengan join, aliran

keluar hanya akan dilakukan jika aliran kedatangan sampai ke join. Dengan

demikikan order hanya bisa ditutup jika pembayaran sudah dilakukan dan

pengiriman sudah dilakukan.

Node pada Activity diagram disebut dengan action bukan activity. Activity

menunjuk ke urutan action, sehingga diagram tersebut menunjukkan activity yang

membangun action.

Perilaku bersyarat ditunjukkan dengan decision dan merge decision hanya

mempunyai satu aliran masuk dan beberapa quard untuk aliran keluar. Setiap

aliran keluar mempunyai sebuah quard yaitu boolean yang ditempatkan pada

kurung kotak. Setiap kali mencapai decision hanya bisa mengambil satu

keputusan, sehingga quard harus mutually exclusive. Penggunaan [else] sebagai

quard menunjukkan bahwa quard yang lain adalah salah.

Dari gambar 2.4 terlihat bahwa setelah order diisi, ada sebuah decision

.Pada saat pesanan lagi sibuk maka perlu pengiriman hingga larut malam jika

tidak pengiriman secara regular tidak mencukupi.

(11)

Sebuah merge mempunyai banyak input dan satu output. Merge mendaki

akhir perilaku bersyarat yang dimulai dengan decision.

Process Sale

PurchasedItem : Item

Bill Customer

Ship Item

Initial Code

Activity Final Code

Gambar 2.4 Contoh Activity diagram Sederhana (Sumber: Prabowo Pudjo

Widodo, Herlawati, 2011)

2.2.3 SEQUENCE DIAGRAM

Sequence Diagram digunakan untuk menggambarkan perilaku pada sebuah

sekenario. Diagram ini menunjukkan sejumlah contoh objek dan message (pesan)

yang diletakkan diantara objek-objek ini di dalam use case. Komponen utama

sequence diagram terdiri atas objek yang dituliskan dengan kotak segiempat

bernama. Message diwakili oleh garis dengan tanda panah dan waktu yang

ditunjukkan dengan progress vertical.

Objek diletakkan di dekat bagian atas diagram dengan urutan dari kiri ke

kanan. Pengertian object hanya ada di UML 1, sedangkan di UML 2 istilah objek

diganti dengan participant.

Setiap participant terhubung dengan garis titik-titik yang disebut lifeline.

Sepanjang lifeline ada kotak yang disebut activation. Activation mewakili sebuah

eksekusi operasi dari participant. Panjang kotak ini berbanding lurus dengan

durasi activation.

(12)

Sebuah message bergerak dari satu participant ke participant yang lain dan

dari satu lifeline ke lifeline yang lain. Sebuah participant pun bisa mengirim pesan

kepada dirinya sendiri. Diagram yang mewakili waktu pada arah vertikal disebut

time. Waktu dimulai dari atas ke bawah. Message yang lebih dekat dari atas akan

dijalankan terlebih dahulu dibanding message yang lebih dekat ke bawah.

Object2 Object1 Actor _{M essage} M essage Activation Lifeline

Gambar 2.5 Simbol-Simbol Yang Ada Pada sequence diagram [Sumber:

Munawar 2005]

Gambar 2.5 menunjukkan esensi simbol dari sequence diagram dan

simbol kerjanya secara bersama sama. Participant terletak di sebelah atas. Setiap

lifeline menggunakan garis putus putus yang menurun dari participant. Garis yang

solid dengan tanda panah menghubungkan antara satu lifeline dengan lifeline yang

lain dan mewakili sebuah message dari satu participant ke participant yang lain.

Dari gambar tersebut terlihat seorang aktor menginisialisasi sequence diagram

meskipun aktor bukan bagian dari sequence diagram.

2.3 BASIS DATA

Data merupakan fakta mengenai suatu objek seperti manusia, benda,

peristiwa, konsep, keadaan dan sebagainya yang dapat dicatat dan mempunyai arti

secara implisit. Data dapat dinyatakan dalam bentuk angka, karakter atau simbol,

sehingga bila data dikumpulkan dan saling berhubungan maka dikenal dengan

(13)

Chou basis data merupakan kumpulan informasi bermanfaat yang diorganisasikan

ke dalam aturan yang khusus. Definisi lain dari basis data menurut Fabbri dan

Schwab adalah sistem berkas terpadu yang dirancang terutama untuk

meminimalkan duplikasi data.

Menurut Ramez Elmasri mendefinisikan basis data lebih dibatasi pada arti

implisit yang khusus, yaitu:

a.

Basis data merupakan penyajian suatu aspek dari dunia nyata (real world).

b.

Basis data merupakan kumpulan data dari berbagai sumber yang secara

logika mempunyai arti implisit. Sehingga data yang terkumpul secara acak

dan tanpa mempunyai arti, tidak dapat disebut basis data.

c.

Basis data perlu dirancang, dibangun dan data dikumpulkan untuk suatu

tujuan. Basis data dapat digunakan oleh beberapa user dan beberapa aplikasi

yang sesuai dengan kepentingan user.

Dari beberapa definisi-definisi tersebut, dapat dikatakan bahwa basis data

mempunyai berbagai sumber data dalam pengumpulan data, bervariasi derajat

interaksi kejadian dari dunia nyata, dirancang dan dibangun agar dapat digunakan

oleh beberapa user untuk berbagai kepentingan [Waliyanto2000].

Data diorganisasikan kedalam bentuk elemen data (field), rekaman (record),

dan berkas (file). Definisi dari ketiganya adalah sebagai berikut:

Elemen data adalah satuan data terkecil yang tidak dapat dipecah lagi

menjadi unit lain yang bermakna. Misalnya data siswa terdiri dari NIS, Nama,

Alamat, Telepon atau Jenis Kelamin.

Rekaman merupakan gabungan sejumlah elemen data yang saling terkait.

Istilah lain dari rekaman adalah baris atau tupel.

(14)

Gambar 2.6 Hirarki Data

Sistem Basis Data

[Waliyanto2000] Gabungan antara basis data dan perangkat lunak SMBD

(Sistem Manajemen Basis Data) termasuk di dalamnya program aplikasi yang

dibuat dan bekerja dalam satu sistem disebut dengan Sistem Basis Data.

Gambar 2.7 Konsep Sistem Basis Data (kompilasi Ramez Elmasri. dkk

1994)

(15)

2.4 Data Base Management System (DBMS)

DBMS dapat diartikan sebagai program komputer yang digunakan untuk

memasukan, mengubah, menghapus, memodifikasi dan memperoleh

data/informasi dengan praktis dan efisien.

Kelebihan dari DBMS antara lain adalah:

• Kepraktisan. DBMS menyediakan media penyimpan permanen yang

berukuran kecil namun banyak menyimpan data jika dibandingkan dengan

menggunakan kertas.

• Kecepatan. Komputer dapat mencari dan menampilkan informasi yang

dibutuhkan dengan cepat.

• Mengurangi kejemuan. Pekerjaan yang berulang-ulang dapat menimbulkan

kebosanan bagi manusia, sedangkan mesin tidak merasakannya.

• Update to date. Informasi yang tersedia selalu berubah dan akurat setiap.

Kelemahan-kelemahan DBMS antara lain:

• Biaya. Kebutuhan untuk medapatkan perangkat lunak dan perangkat keras

yang tepat cukup mahal, termasuk biaya pemeliharaan dan sumber daya

manusia yang mengelola basis data tersebut.

• Sangat kompleks. Sistem basis data lebih kompleks dibandingkan dengan

proses berkas, sehingga dapat mudah terjadinya kesalahan dan semakin sulit

dalam pemeliharaan data.

• Resiko data yang terpusat. Data yang terpusat dalam satu lokasi dapat

beresiko kehilangan data selama proses aplikasi.

2.5 Entity Relationship Diagram

2.5.1 Konsep Dasar Model Entity Relationship

Model Entity Relationship diperkenalkan pertama kali oleh P.P. Chen pada

tahun 1976. Model ini dirancang untuk menggambarkan persepsi dari pemakai

dan berisi obyek-obyek dasar yang disebut entity dan hubungan antar entity-entity

tersebut yang disebut relationship. Pada model ER ini semesta data yang ada

(16)

dalam dunia nyata ditransformasikan dengan memanfaatkan perangkat konseptual

menjadik sebuah diagram, yaitu diagram ER ( Entity Relationship)

Diagram Entity-Relationship melengkapi penggambaran grafik dari struktur

logika . Dengan kata lain Diagram E-R menggambarkan arti dari aspek data

seperti bagaimana entity-entity, atribut-atribut dan relationship-relationship

disajikan. Sebelum membuat Diagram E-R , tentunya kita harus memahami betul

data yang diperlukan dan ruang lingkupnya. Di dalam pembuatan diagram E-R

perlu diperhatikan penentuan sesuatu konsep apakah merupakan suatu entity,

atribut atau relationship.

Gambar 2.8 Contoh Entity Relationship Diagram

2.5.2 Tipe Entity

Entity adalah obyek yang dapat dibedakan dengan yang lain dalam dunia

nyata. Entity dapat berupa obyek secara fisik seperti orang, rumah, atau

kendaraan. Entity dapat pula berupa obyek secara konsep seperti pekerjaan ,

perusahaan, dan sebagainya.

Tipe entity merupakan sekumpulan obyek dalam dunia nyata yang

mempunyai properti yang sama atau berasal dari entity yang sejenis. Terdapat dua

tipe Entity, Entity Kuat dan Entity Lemah. Entity kuat adalah entity yang

keberadaanya tidak tergantung pada entity lain, misalkan tipe entity pegawai atau

cabang. Sedangkan Entity Lemah keberadaanya tergantung pada entity lain,

misalkan tipe entity tanggungan, dimana keberadaannya tergantung dari pegawai .

Entity disajikan dalam bentuk persegi panjang, entity kuat disajikan dengan

perseg panjang dengan satu garis, sedangkan entity lemah disajikan dengan

persegi panjang dobel.

(17)

2.5.3 Atribut

Atribut adalah karakteristik dari entity atau relationship, yang menyediakan

penjelasan detail tentang entity atau relationship tersebut. Nilai Atribut merupakan

suatu data aktual atau informasi yang disimpan pada suatu atribut di dalam suatu

entity atau relationship. Atribut digambarkan dalam bentuk oval.

Jenis-jenis atribut :

Key

Atribut yang digunakan untuk menentukan suatu entity secara unik.

Atribut Simple

Atribut yang bernilai tunggal.

Atribut Multivalue

Atribut yang memiliki sekelompok nilai untuk setiap instan entity.

Atribut Composite

Suatu atribut yang terdiri dari beberapa atribut yang lebih kecil yang

mempunyai arti tertentu.

Atribut Derivatif

Suatu atribut yang dihasilkan dari atribut yang lain.

2.6 PHP

Pada awalnya PHP merupakan singkatan dari Personal Home Page tools,

sebuah tool (alat bantu) untuk memonitor pengunjung suatu web. PHP mula-mula

dikembangkan oleh Rasmus Lerdof. Istilah PHP kemudian lebih mengacu pada

Hypertext Prepocesor. PHP kemudian lebih dikembangkan untuk membangun

aplikasi web, mendukung database (i.e mySQL/Oracle) dan memproses berbagai

form. Untuk dapat menjalankan PHP dibutuhkan suatu sistem yang telah

terkonfigurasi dengan baik. Sistem ini meliputi suatu web server (i.e Apache Web

Server), tools (PHP) dan database (MySQL). Ketiganya merupakan suatu bentuk

open source yang dapat berjalan multi platform (Windows maupun Linux/Unix).

Tujuan utama penggunaan bahasa ini adalah untuk memungkinkan perancang

web menulis halaman web dinamik dengan cepat. Program PHP harus

diterjemahkan oleh web-server sehingga menghasilkan kode html yang dikirim ke

browser agar dapat ditampilkan. Program ini dapat berdiri sendiri ataupun

(18)

disisipkan di antara kode-kode html sehingga dapat langsung ditampilkan bersama

dengan kode-kode HTML tersebut. Program PHP dapat ditambahkan dengan

mengapit program tersebut diantara tanda. Tanda-tanda tersebut biasanya disebut

tanda untuk escaping (kabur) dari kode HTML. File HTML yang telah dibubuhi

program PHP harus diganti ekstensi-nya menjadi .php3 atau .php. karena PHP

merupakan bahasa pemrograman web yang bersifat server-side.

2.7 XAMPP

XAMPP merupakan tool yang menyediakan paket perangkat lunak ke dalam

satu buah paket. Dengan menginstall XAMPP maka tidak perlu lagi melakukan

instalasi dan konfigurasi web server Apache, PHP dan MySQL secara manual.

XAMPP akan menginstalasi dan mengkonfigurasikannya secara otomatis untuk

anda atau auto konfigurasi. Versi XAMPP yang ada saat ini adalah Versi 1.4.14

atau yang terbarunya anda bisa download pada

http://www.apachefriends.org/en/xampp-window.html

2.8 Algoritma First Come First Serve

Algoritma First Come First Serve (FCFS) disebut juga sebagai teknik

Pertama Tiba Pertama Dilayani (PTPD). FCFS merupakan penjadwalan tanpa

prioritas dan tanpa preempsi (lihat posting penjadwalan cpu). Karena itu, proses

ini serentak tersusun dalam antrian murni.

FCFS dapat menyebabkan banyak waktu untuk seek silinder yang paling

dalam ke silinder paling luar. Ketika permintaan-permintaan terdistribusi seragam

pada permukaan-permukaan disk, penjadwalan FCFS menghasilkan pola seek

yang acak. FCFS mengabaikan keterhubungan posisi di antara

permintaan-permintaan yang menunggu di antrian. FCFS tidak membuat upaya optimasi pola

seek (Sumber: Bambang Harianto, 1997)

(19)

Tabel 2.3 Antrian Lima Proses dengan saat tiba = 0

Nama Proses

Saat Tiba

Lama Proses

A

B

C

D

E

0

7

10

2

4

8 Tabel 2.4 Antrian Lima Proses saat tiba berbeda

Nama Proses

Saat Tiba

Lama Proses

A

B

C

D

E

0

1

8

2

5

7

10

2

4

8 Kita dapat langsung memasukkan proses ini ke dalam tabel proses pada

kerja prosesor. Pada contoh kasus I, proses B hanya dapat dilaksanakan setelah

proses A rampung dilaksanakan. Proses C hanya dapat dilaksanakan setelah

proses B rampung dilaksanakan.

Pada Gambar Contoh kasus di bagian atas postingan ini, proses belum

terurut sesuai waktu tibanya, oleh karena itu setelah diurut berdasarkan waktu

tibanya, maka antrian menjadi A, B, D, E, dan C. Tampak di sini bahwa rerata

lama tanggap adalah 17,8 satuan waktu. Nilai ini masih cukup besar dibandingkan

dengan lama proses dari masing-masing proses tetapi masih lebih kecil dari rerata