BAB II LANDASAN TEORI

BAB II LANDASAN TEORI 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.

5

http://digilib.mercubuana.ac.id/

6

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 berbedabeda, biasanya model-model tersebut mengikuti pola umum analysis – design – coding – testing - maintenance. • Stakeholder

berperan

tahapan pengembangan.

sangat

penting

dalam

keseluruhan

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.


7

Keluaran dari proses pengembangan perangkat lunak harus bernilah ekonomis. Nilai dari sebuah perangkat lunak sebenarnya agak susah di- rupiahkan Namun efek dari penggunaan perangkat lunak yang telah dikembangkan 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.

Rekayasa dan Pemodelan Sistem Analisa Kebutuhan Desain

Pengkodean

Pengujian

Pemeliharaan

Gambar 2.2 Model Waterfall 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


8

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


9

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.


10

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

Sudah ada di UML 1


11

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 langkahlangkah 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.


12

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.

Sistem

Use Case Actor

Actor

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 processrelevant 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)


13

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

dekomposisi

Tanda waktu

Tanda pengiriman

Tanda penerimaan


adanya

14

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.


15

Sebuah merge mempunyai banyak input dan satu output. Merge mendaki akhir perilaku bersyarat yang dimulai dengan decision.

Process Sale PurchasedItem : Item

Bill Customer

Initial Code

Ship Item

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.


16

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

Lifeline Activation

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 istilah basis data (database) [Ramez2000]. Sedangkan menurut George Tsu-der


17

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. Berkas adalah himpunan seluruh rekaman yang bertipe sama.


18

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)


19

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


20

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.


21

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


22

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 permintaanpermintaan yang menunggu di antrian. FCFS tidak membuat upaya optimasi pola seek (Sumber: Bambang Harianto, 1997)


23

Tabel 2.3 Antrian Lima Proses dengan saat tiba = 0

Nama Proses A B C D E

Saat Tiba 0 0 0 0 0

Lama Proses 7 10 2 4 8

Tabel 2.4 Antrian Lima Proses saat tiba berbeda

Nama Proses A B C D E

Saat Tiba 0 1 8 2 5

Lama Proses 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 lama tanggap untuk kasus I. Perbedaan dengan contoh pertama terletak pada perhitungan lama tanggap. Kalau pada contoh pertama, lama tanggap sama dengan saat rampung, maka di sini mereka tidak sama karena saat tiba proses tidaklah sama. Kedua contoh ini menunjukkan bahwa lama tanggap sangat dipengaruhi oleh lama proses pada proses yang terletak di bagian depan antrian. Jika lama proses pada proses di bagian depan antrian itu besar, maka proses dengan lama proses yang singkat di bagian belakang antrian, tetap harus lama menunggu, sebelum mereka dapat dilayani oleh prosesor. Itu sebabnya penjadwalan FCFS ini kurang menguntungkan bagi keseluruhan pelayanan.


24

Salah satu cara untuk mengatasi hal itu adalah melalui prioritas. Proses dengan lama proses yang singkat memperoleh prioritas untuk didahulukan ke prosesor. Makin singkat masa prosesnya, makin cepat proses itu dilayani oleh prosesor. Penjadwalan ini dikenal sebagai Proses Terpendek Dipertamakan.


BAB II LANDASAN TEORI

Recommend Documents