Model UML

Pengenalan "Unified Modeling Language/UML"
(Bagian I)
Dalam suatu proses pengembangan software, analisa dan rancangan telah
merupakan terminologi yang sangat tua. Pada saat masalah ditelusuri dan
spesifikasi dinegoisasikan, dapat dikatakan kita berada pada tahap rancangan.
Merancang adalah menemukan suatu cara untuk menyelesaikan masalah, salah
satu tool / model untuk merancang pengembangan software yang berbasis object
oriented adalah UML.

Konsep Objek
Obyek dalam ‘software analysis & design’ adalah sesuatu berupa konsep
(concept), benda (thing), dan sesuatu yang membedakannya dengan
lingkungannya. Secara sederhana obyek adalah mobil, manusia, alarm dan lainlainnya.
Tapi obyek dapat pula merupakan sesuatu yang abstrak yang hidup
didalam sistem seperti tabel, database, event, system messages.
Obyek dikenali dari keadaannya dan juga operasinya. Sebagai contoh sebuah
mobil dikenali dari warnanya, bentuknya, sedangkan manusia dari suaranya. Ciriciri
ini yang akan membedakan obyek tersebut dari obyek lainnya.
Alasan mengapa saat ini pendekatan dalam pengembangan software dengan
object-oriented, pertama adalah scalability dimana obyek lebih mudah dipakai
untuk menggambarkan sistem yang besar dan komplek. Kedua dynamic
modeling, adalah dapat dipakai untuk permodelan sistem dinamis dan real time.

Teknik Dasar OOA/D (Object-Oriented Analysis/Design)
Dalam dunia pemodelan, metodologi implementasi obyek walaupun terikat
kaidah-kaidah standar, namun teknik pemilihan obyek tidak terlepas pada
subyektifitas software analyst & designer. Beberapa obyek akan diabaikan dan
beberapa obyek menjadi perhatian untuk diimplementasikan di dalam sistem. Hal
ini sah-sah saja karena kenyataan bahwa suatu permasalahan sudah tentu
memiliki lebih dari satu solusi. Ada 3 (tiga) teknik/konsep dasar dalam OOA/D,
yaitu pemodulan (encapsulation), penurunan (inheritance) dan polymorphism.

a. Pemodulan (Encapsulation)
Pada dunia nyata, seorang ibu rumah tangga menanak nasi dengan
menggunakan rice cooker, ibu tersebut menggunakannya hanya dengan menekan
tombol. Tanpa harus tahu bagaimana proses itu sebenarnya terjadi. Disini
terdapat penyembunyian informasi milik rice cooker, sehingga tidak perlu
diketahui seorang ibu. Dengan demikian menanak nasi oleh si ibu menjadi
sesuatu yang menjadi dasar bagi konsep information hiding.

b. Penurunan (Inheritance)
Obyek-obyek memiliki banyak persamaan, namun ada sedikit perbedan. Contoh
dengan beberapa buah mobil yang mempunyai kegunaan yang berbeda-beda.
Ada mobil bak terbuka seperti truk, bak tertutup seperti sedan dan minibus.
Walaupun demikian obyek-obyek ini memiliki kesamaan yaitu teridentifikasi
sebagai obyek mobil, obyek ini dapat dikatakan sebagai obyek induk (parent).
Sedangkan minibus dikatakan sebagai obyek anak (child), hal ini juga berarti
semua operasi yang berlaku pada mobil berlaku juga pada minibus.

c. Polymorphism
Pada obyek mobil, walaupun minibus dan truk merupakan jenis obyek mobil yang
sama, namun memiliki juga perbedaan. Misalnya suara truk lebih keras dari pada
minibus, hal ini juga berlaku pada obyek anak (child) melakukan metoda yang
sama dengan algoritma berbeda dari obyek induknya. Hal ini yang disebut
polymorphism, teknik atau konsep dasar lainnya adalah ruang lingkup /
pembatasan. Artinya setiap obyek mempunyai ruang lingkup kelas, atribut, dan
metoda yang dibatasi.

Sejarah Singkat UML
UML (Unified Modeling Language) adalah sebuah bahasa yang berdasarkan
grafik/gambar untuk memvisualisasi, menspesifikasikan, membangun, dan
pendokumentasian dari sebuah sistem pengembangan software berbasis OO
(Object-Oriented). UML sendiri juga memberikan standar penulisan sebuah sistem
blue print, yang meliputi konsep bisnis proses, penulisan kelas-kelas dalam
bahasa program yang spesifik, skema database, dan komponen-komponen yang
diperlukan dalam sistem software (http://www.omg.org).

Pendekatan analisa & rancangan dengan menggunakan model OO mulai
diperkenalkan sekitar pertengahan 1970 hingga akhir 1980 dikarenakan pada
saat itu aplikasi software sudah meningkat dan mulai komplek. Jumlah yang
menggunakaan metoda OO mulai diuji cobakandan diaplikasikan antara 1989
hingga 1994, seperti halnya oleh Grady Booch dari Rational Software Co., dikenal
dengan OOSE (Object-Oriented Software Engineering), serta James Rumbaugh
dari General Electric, dikenal dengan OMT (Object Modelling Technique).

Kelemahan saat itu disadari oleh Booch maupun Rumbaugh adalah tidak adanya
standar penggunaan model yang berbasis OO, ketika mereka bertemu ditemani
rekan lainnya Ivar Jacobson dari Objectory mulai mendiskusikan untuk
mengadopsi masing-masing pendekatan metoda OO untuk membuat suatu model
bahasa yang uniform / seragam yang disebut UML (Unified Modeling Language)
dan dapat digunakan oleh seluruh dunia.

Secara resmi bahasa UML dimulai pada bulan oktober 1994, ketika Rumbaugh
bergabung Booch untuk membuat sebuah project pendekatan metoda yang
uniform/seragam dari masing-masing metoda mereka. Saat itu baru
dikembangkan draft metoda UML version 0.8 dan diselesaikan serta di release
pada bulan oktober 1995. Bersamaan dengan saat itu, Jacobson bergabung dan
UML tersebut diperkaya ruang lingkupnya dengan metoda OOSE sehingga muncul
release version 0.9 pada bulan Juni 1996. Hingga saat ini sejak Juni 1998 UML
version 1.3 telah diperkaya dan direspons oleh OMG (Object Management Group),
Anderson Consulting, Ericsson, Platinum Technology, ObjectTime Limited, dll
serta di pelihara oleh OMG yang dipimpin oleh Cris Kobryn.

UML adalah standar dunia yang dibuat oleh Object Management Group (OMG),
sebuah badan yang bertugas mengeluarkan standar-standar teknologi objectoriented
dan software component.

3. Pengenalan UML
UML sebagai sebuah bahasa yang memberikan vocabulary dan tatanan penulisan
kata-kata dalam ‘MS Word’ untuk kegunaan komunikasi. Sebuah bahasa model
adalah sebuah bahasa yang mempunyai vocabulary dan konsep tatanan / aturan
penulisan serta secara fisik mempresentasikan dari sebuah sistem. Seperti halnya
UML adalah sebuah bahasa standard untuk pengembangan sebuah software yang
dapat menyampaikan bagaimana membuat dan membentuk model-model, tetapi
tidak menyampaikan apa dan kapan model yang seharusnya dibuat yang
merupakan salah satu proses implementasi pengembangan software.
UML tidak hanya merupakan sebuah bahasa pemograman visual saja, namun
juga dapat secara langsung dihubungkan ke berbagai bahasa pemograman,
seperti JAVA, C++, Visual Basic, atau bahkan dihubungkan secara langsung ke
dalam sebuah object-oriented database. Begitu juga mengenai
pendokumentasian dapat dilakukan seperti; requirements, arsitektur, design,
source code, project plan, tests, dan prototypes.

Untuk dapat memahami UML membutuhkan bentuk konsep dari sebuah bahasa
model, dan mempelajari 3 (tiga) elemen utama dari UML seperti building block,
aturan-aturan yang menyatakan bagaimana building block diletakkan secara
bersamaan, dan beberapa mekanisme umum (common).

a. Building blocks
3 (tiga) macam yang terdapat dalam building block adalah katagori
benda/Things, hubungan, dan diagram. Benda/things adalah abstraksi yang
pertama dalam sebuah model, hubungan sebagai alat komunikasi dari bendabenda,
dan diagram sebagai kumpulan / group dari benda-benda/things.

• Benda/Things
Adalah hal yang sangat mendasar dalam model UML, juga merupakan bagian
paling statik dari sebuah model, serta menjelaskan elemen-elemen lainnya dari
sebuah konsep dan atau fisik. Bentuk dari beberapa benda/thing adalah sebagai
berikut:

Pertama, adalah sebuah kelas yang diuraikan sebagai sekelompok dari object
yang mempunyai atribute, operasi, hubungan yang semantik. Sebuah kelas
mengimplementasikan 1 atau lebih interfaces. Sebuah kelas dapat digambarkan
sebagai sebuah persegi panjang, yang mempunyai sebuah nama, atribute, dan
metoda pengoperasiannya.

Kedua, yang menggambarkan ‘interface’ merupakan sebuah antar-muka yang
menghubungkan dan melayani antar kelas dan atau elemen. ‘Interface’ / antarmuka
mendefinisikan sebuah set / kelompok dari spesifikasi pengoperasian,
umumnya digambarkan dengan sebuah lingkaran yang disertai dengan namanya.
Sebuah antar-muka berdiri sendiri dan umumnya merupakan pelengkap dari
kelas atau komponen.

Ketiga, adalah collaboration yang didefinisikan dengan interaksi dan sebuah
kumpulan / kelompok dari kelas-kelas/elemen-elemen yang bekerja secara
bersama-sama. Collaborations mempunyai struktura dan dimensi. Pemberian
sebuah kelas memungkinkan berpartisipasi didalam beberapa collaborations dan
digambarkan dengan sebuah ‘elips’ dengan garis terpotong-potong.

Keempat, sebuah ‘use case’ adalah rangkaian/uraian sekelompok yang saling
terkait dan membentuk sistem secara teratur yang dilakukan atau diawasi oleh
sebuah aktor. ‘use case’ digunakan untuk membentuk tingkah-laku benda/ things
dalam sebuah model serta di realisasikan oleh sebuah collaboration. Umumnya
‘use case’ digambarkan dengan sebuah ‘elips’ dengan garis yang solid, biasanya
mengandung nama.

Kelima, sebuah node merupakan fisik dari elemen-elemen yang ada pada saat
dijalankannya sebuah sistem, contohnya adalaha sebuah komputer, umumnya
mempunyai sedikitnya memory dan processor. Sekelompok komponen mungkin
terletak pada sebuah node dan juga mungkin akan berpindah dari node satu ke
node lainnya. Umumnya node ini digambarkan seperti kubus serta hanya
mengandung namanya.

• Hubungan / Relationship
Ada 4 macam hubungan didalam penggunaan UML, yaitu; dependency,
association, generalization, dan realization.
Pertama, sebuah dependency adalah hubungan semantik antara dua
benda/things yang mana sebuah benda berubah mengakibatkan benda satunya
akan berubah pula. Umumnya sebuah dependency digambarkan sebuah panah
dengan garis terputus-putus.

Kedua, sebuah association adalah hubungan antar benda struktural yang
terhubung diantara obyek. Kesatuan obyek yang terhubung merupakan hubungan
khusus, yang menggambarkan sebuah hubungan struktural diantara seluruh atau
sebagian. Umumnya assosiation digambarkan dengan sebuah garis yang
dilengkapi dengan sebuah label, nama, dan status hubungannya.

Ketiga, sebuah generalization adalah menggambarkan hubungan khusus dalam
obyek anak/child yang menggantikan obyek parent / induk . Dalam hal ini, obyek
anak memberikan pengaruhnya dalam hal struktur dan tingkah lakunya kepada
obyek induk. Digambarkan dengan garis panah.

Keempat, sebuah realization merupakan hubungan semantik antara
pengelompokkan yang menjamin adanya ikatan diantaranya. Hubungan ini dapat
diwujudkan diantara interface dan kelas atau elements, serta antara use cases
dan collaborations. Model dari sebuah hubungan realization.

• Diagram
UML sendiri terdiri atas pengelompokkan diagram-diagram sistem menurut
aspek atau sudut pandang tertentu. Diagram adalah yang menggambarkan
permasalahan maupun solusi dari permasalahan suatu model. UML mempunyai 9
diagram, yaitu; use-case, class, object, state, sequence, collaboration, activity,
component, dan deployment diagram.

Diagram pertama adalah use case menggambarkan sekelompok use cases dan
aktor yang disertai dengan hubungan diantaranya. Diagram use cases ini
menjelaskan dan menerangkan kebutuhan / requirement yang diinginkan/
dikehendaki user/pengguna, serta sangat berguna dalam menentukan struktur
organisasi dan model dari pada sebuah sistem.

Pengenalan "Unified Modelling Language/UML"
(Bagian II)

Dalam suatu proses pengembangan software, analisa dan rancangan telah
merupakan terminologu yang sangat tua. Pada saat masalah ditelusuri dan
spesifikasi dinegosiasikan, dapat dikatakan bahwa kita berada pada tahap
rancangan. merancang adalah menemukan suatu cara untuk menyelesaikan
masalah, salah satu tool/model untuk merancang pengembangan software yang
berbasis object-oriented adalah UML. Alasan mengapa UML digunakan adalah,
pertama, scalability dimana objek lebih mudah dipakai untuk menggambarkan
sistem yang besar dan komplek. Kedua, dynamic modeling, dapat dipakai untuk
pemodelan sistem dinamis dan real time.

Sebagaimana dalam tulisan pertama, penulis menjelaskan konsep mengenai
obyek, OOA&D (Obyek Oriented Analyst/ Design) dan pengenalan UML, maka
dalam tulisan kedua ini lebih ditekankan pada cara bagaimana UML digunakan
dalam merancang sebuah pengembangan software yang disertai gambar atau
contoh dari sebuah aplikasi.

1. Use Case
Sebuah use case menggambarkan suatu urutan interaksi antara satu atau lebih
aktor dan sistem. Dalam fase requirements, model use case mengambarkan
sistem sebagai sebuah kotak hitam dan interaksi antara aktor dan sistem dalam
suatu bentuk naratif, yang terdiri dari input user dan respon-respon sistem.
Setiap use case menggambarkan perilaku sejumlah aspek sistem, tanpa
mengurangi struktur internalnya. Selama pembuatan model use case secara
pararel juga harus ditetapkan obyek-obyek yang terlibat dalam setiap use case.
Perhatikan satu contoh sederhana dari proses perbankan, yaitu mesin teller
otomatis (Automated Teller Machine-ATM) yang memberikan kemudahan pada
customernya untuk mengambil uang dari rekening bank secara langsung. Pada
proses ini terdapat satu aktor, yaitu ATM Customer dan satu use case, yaitu
Penarikan Dana. Proses ini dapat dilihat pada Gambar 1. Use case Penarikan
Dana menggambarkan urutan interaksi antara customer dengan sistem, diawali
ketika customer memasukan kartu ATM ke dalam mesin pembaca kartu dan
akhirnya menerima pengeluaran uang yang dilakukan oleh mesin ATM.

2. Aktor
Sebuah aktor mencirikan suatu bagian outside user atau susunan yang berkaitan
dengan user yang berinteraksi dengan sistem [Rumbaugh, Booch, dan Jacobson
1999]. Dalam model use case, aktor merupakan satu-satunya kesatuan eksternal
yang berinteraksi dengan sistem.

Terdapat beberapa variasi bagaimana aktor dibentuk [Fowler dan Scott 1999].
Sebuah aktor sering kali merupakan manusia (human user). Pada sejumlah
sistem informasi, manusia adalah satu-satunya aktor. Dan mungkin saja dalam
sistem informasi, seorang aktor bisa saja menjadi suatu sistem eksternal. Pada
aplikasi real-time dan distribusi, sebuah aktor bisa saja menjadi satu perangkat
eksternal I/O atau sebuah alat pengatur waktu. Perangkat eksternal I/O dan
pengatur waktu aktor secara khusus lazimnya berada dalam real-time yang
tersimpan dalam sistem (real-time embedded systems), sistem berinteraksi
dengan lingkungan eksternal melalui sensor dan aktuator.

Primary actor (aktor utama) memprakarsai sebuah use case. Jadi, suatu primary
aktor memegang peran sebagai proaktif dan yang memulai aksi dalam sistem.
Aktor lainnya yang berperan sebagai secondary aktor bisa saja terlibat dalam use
case dengan menerima output dan memberikan input. Setidaknya satu aktor
harus mendapatkan nilai dari use case. Biasanya adalah primary aktor (aktor
utama). Bagaimanapun, dalam real-time embedded systems, primary aktor dapat
berperan sebagai perangkat eksternal I/O atau pengatur waktu, penerima utama
dari use case bisa menjadi secondary human aktor yang menerima sejumlah
informasi dari sistem.




Aktor manusia bisa saja menggunakan berbagai perangkat I/O untuk berinteraksi
fisik dengan sistem. Aktor manusia dapat berinteraksi dengan sistem melalui
perangkat standar I/O, seperti keyboard, display, atau mouse. Aktor manusia
bisa juga berinteraksi dengan sistem melalui perangkat non-standar I/O seperti
bermacam-macam sensor. Dalam keseluruhan hal tersebut, manusia merupakan
aktor dan perangkat I/O adalah bukan aktor.

Perhatikan beberapa contoh human aktor (aktor manusia). Pada sistem
perbankan, satu contoh aktor adalah manusia yang berperan sebagai teller yang
berinteraksi dengan sistem melalui perangkat standar I/O, seperti keyboard,
display, atau mouse. Contoh lainnya adalah manusia yang berperan sebagai
customer yang berinteraksi dengan sistem melalui mesin teller otomatis (ATM).
Dalam hal ini, customer berinteraksi dengan sistem dengan menggunakan
beberapa perangkat I/O, termasuk perangkat pembaca kartu (card reader),
pengeluar uang (cash dispenser), dan pencetak tanda terima (receipt printer),
ditambah lagi keyboard dan display.

Pada beberapa kasus, bagaimana pun juga sebuah aktor bisa saja berupa
perangkat I/O. Hal ini bisa terjadi ketika sebuah use case tidak melibatkan
manusia, seperti yang sering terjadi pada aplikasi-aplikasi real-time. Dalam hal
ini, I/O aktor berinteraksi dengan sistem melalui sebuah sensor. Contoh aktor
yang merupakan perangkat input adalah Arrival Sensor pada Sistem Kontrol
Elevator. Sensor ini mengidentifikasi elevator tersebut pada saat hendak
mencapai lantai dan perlu dihentikan. Kemudian sensor tersebut menginisiasikan
Stop Elevator at Floor use case. Aktor lain dalam Elevator Control System adalah
orang yang berada dalam elevator (human passenger) yang berinteraksi dengan
sistem melalui tombol-tombol nomor pada tingkat lantai dan tombol-tombol
elevator. Input dari aktor secara aktual dideteksi melalui sensor-sensor tombol
lantai dan sensor-sensor tombol elevator berturut-turut.

Aktor dapat pula menjadi sebuah alat pengukur waktu yang secara periodik
mengirimkan pengukuran waktu kejadian (timer events) pada sistem. Use case-use case secara periodik diperlukan ketika beberapa informasi perlu di-output
oleh sistem pada suatu basis reguler. Hal ini sangat penting dalam sistem-sistem
real-time, dan juga sangat berguna dalam sistem informasi. Walaupun sejumlah
metodologi menganggap pengukur waktu merupakan hal internal bagi sistem,
dan akan lebih berguna dalam desain aplikasi real-time untuk memperhatikan
pengukur-pengukur waktu sebagai eksternal logis bagi sistem dan
menganggapnya sebagai primary aktor yang memulai aksi dalam sistem.
Contohnya, pada sistem monitoring mobil, beberapa use case di-inisialisasi
dengan suatu aktor pengukur waktu. Sebagai contoh dapat dilihat pada Gambar

2. Timer aktor mengawali Calculate Trip Speed use case, yang secara periodik
menghitung rata-rata kecepatan melalui suatu jalan/ jejak dan menampilkan nilai
ini ke driver. Dalam hal ini, pengukur waktu merupakan primary aktor (aktor
utama) dan driver merupakan secondary aktor (aktor kedua).

Suatu aktor bisa juga menjadi sistem eksternal yang melakukan inisiatif (sebagai
primary aktor) atau partisipan (sebagai secondary aktor) dalam use case. Satu
contoh aktor sistem eksternal adalah pabrik robot dalam Automation System.
Robot mengawali proses dengan use case Generate Alarm dan Notify, robot
menggerakkan alarm conditions yang dikirim ke operator pabrik yang
berkepentingan, yang telah terdaftar untuk menerima alarms. Dalam use case ini,
robot merupakan primary aktor yang mengawali inisiatif use case, dan operator
merupakan secondary aktor yang menerima alarms.

3. Identifikasi Use Case
Sebuah use case dimulai dengan masukan/input dari seorang aktor. Use case
merupakan suatu urutan lengkap kejadian-kejadian yang diajukan oleh seorang
aktor, dan spesifikasi interaksi antara aktor dengan sistem. Use case yang
sederhana hanya melibatkan satu interaksi/hubungan dengan sebuah aktor, dan
use case yang lebih kompleks melibatkan beberapa interaksi dengan aktor. Use
cases yang lebih kompleks juga melibatkan lebih dari satu aktor.

Untuk menjabarkan use case dalam sistem, sangat baik bila dimulai dengan
memperhatikan aktor dan actions/aksi yang mereka lakukan dalam sistem.
Setiap use case menggambarkan suatu urutan interaksi antara aktor dengan
sistem. Sebuah use case harus memberikan sejumlah nilai pada satu aktor.
Kemudian, kebutuhan fungsional sistem dijelaskan dalam use case yang
merupakan suatu spesifikasi eksternal dari sebuah sistem. Bagaimanapun juga,
ketika membuat use case, sangatlah penting menghindari suatu dekomposisi
fungsional yang dalam beberapa use case kecil lebih menjelaskan fungsi-fungsi individual sistem daripada menjelaskan urutan kejadian yang memberikan hasil
yang berguna bagi aktor.

Perhatikan lagi contoh pada perbankan. Disamping penarikan melalui ATM, ATM
Customer, aktor juga bisa menanyakan jumlah rekening atau mentransfer dana
antar dua rekening. Karena terdapat fungsi-fungsi yang berbeda yang diajukan
oleh customer dengan hasil-hasil guna yang berbeda, fungsi-fungsi pertanyaan
dan pentransferan harus dibuat sebagai use case yang terpisah, daripada
menjadi bagian dari original use case. Oleh karena itu, customer dapat
mengajukan tiga use case seperti yang dapat dilihat di Gambar. 3; Withdraw
Funds (Penarikan dana), Query Account, dan Transfer Funds (Pentransferan
Dana).

Urutan utama use case menjelaskan urutan interaksi yang paling umum antara
aktor dan sistem. Dan mungkin saja terdapat cabang-cabang urutan use case
utama, yang mengarah pada berkurangnya frekuensi interaksi antara aktor
dengan sistem. Deviasi-deviasi dari urutan utama hanya dilaksanakan pada
beberapa situasi, contohnya jika aktor melakukan kesalahan input pada sistem.
Ketergantungan pada aplikasi kebutuhan, alternatif ini memecahkan use case dan
kadang-kadang bersatu kembali dengan urutan utama. Cabang-cabang alternatif
digambarkan juga dalam use case.
Dalam use case Withdraw Funds, urutan utama adalah urutan tahap-tahap
dalam keberhasilan pelaksanaan penarikan (withdrawal). Cabang-cabang
alternatif digunakan untuk mengarahkan berbagai error cases, seperti ketika
kartu ATM tidak dikenali atau dilaporkan telah hilang dan lain sebagainya.

4. Pendokumentasian Model Use Case
Use case didokumentasi dalam use case model sebagai berikut:
• Use Case Name. Setiap use case diberi nama.
• Summary. Deskripsi singkat use case, biasanya satu atau dua kalimat.
• Dependency. Bagian ini menggambarkan apakah use case yang satu
tergantung pada use case yang lain, dalam arti apakah use case tersebut
termasuk pada use case yang lain atau malah memperluas use case lain.

• Actors. Bagian ini memberikan nama pada actor dalam use case. Selalu
terdapat use case utama (primary use case) yang memulai use case.
Disamping itu terdapat juga secondary use case yang terlibat dalam use
case. Contohnya, dalam use case Withdraw Funds, ATM Customer adalah
actor-nya.
• Preconditions. Satu atau lebih kondisi harus berjalan dengan baik pada
permulaan use case; contohnya mesin ATM yang tidak jalan, menampilkan
pesan Selamat Datang.

• Deskripsi. Bagian terbesar dari use case merupakan deskripsi naratif dari
urutan utama use case yang merupakan urutan yang paling umum dari
interaksi antara aktor dan sistem. Deskripsi tersebut dalam bentuk input
dari aktor, diikuti oleh respon pada sistem. Sistem ditandai dengan sebuah
kotak hitam (black box) yang berkaitan dengan apa yang sistem lakukan
dalam merespon input aktor, bukan bagaimana internal melakukannya.

• Alternatif-alternatif. Deskripsi naratif dari alternatif merupakan cabang
dari urutan utama. Terdapat beberapa cabang alternatif dari urutan
utama. Contohnya, jika rekening customer terdapat dana yang tidak
sesuai, akan tampil permohonan maaf dan menolak kartu.

• Postcondition. Kondisi yang selalu terjadi di akhir use case, jika urutan
utama telah dilakukan; contohnya dana customer telah ditarik.

• Outstanding questions. Pertanyaan-pertanyaan tentang use case
didokumentasikan untuk didiskusikan dengan para user.

Download PDF

Metode Unified Approach (UA)

Metode Pengembangan Sistem

Dalam Pengembangan sistem, akan digunakan pendekatan berorientasi objek dengan Unified Approach (UA). UA adalah suatu metodologi pengembangan sistem berbasis objek yang menggabungkan proses dan metodologi yang telah ada sebelumnya dan menggunakan UML sebagai standar pemodelannya. Proses dan tahapan yang ada dalam UA merupakan proses-proses terbaik yang diambil dari metode objek yang telah diperkenalkan oleh Booch, Rumbaugh, dan Jacobson. Selain itu, langkah-langkah yang ada dalam UA sangat iteratif dan memudahkan pengembang sistem dalam memahami sistem sehingga UA dijadikan sebagai metodologi pengembangan sistem dalam Tugas Akhir ini.

Tahap Analisis dalam UA ditujukan untuk mengidentifikasi kelas-kelas yang terdapat dalam sistem. Kelas-kelas yang telah teridentifikasi sebagai output di tahap analisis akan dijadikan input pada tahap perancangan. Sementara itu, output dari tahap perancangan adalah perangkat lunak yang telah dirancang sesuai dengan kebutuhan user.

Langkah-langkah yang harus dilakukan pada metodologi UA dari Ali Bahrami (1999) adalah sebagai berikut:

1. Tahap Analisis

Gambar 1.1: Tahap Analisis UA

Keterangan:

* Identifikasi Aktor

Tahap menganalisis aktor yang akan berinteraksi dengan sistem

* Pengembangan Diagram Use Case dan Diagram Aktifitas

Tahap yang menggambarkan alur kerja sistem dalam diagram aktifitas dan menggambarkan interaksi antara user dengan sistem dalam diagram use case

* Pengembangan Diagram Interaksi

Diagram interaksi yang digunakan adalah sequence diagram, dalam diagram ini digambarkan interaksi antar objek dalam sistem melalui pesan yang dikirimkan dari objek yang satu ke objek yang lain.

* Identifikasi Kelas-kelas, relasi, atribut dan method

Proses mengidentifikasi kelas, relasi, atribut dan method dalam sistem berdasarkan proses sebelumnya.

* Pemeriksaan terhadap tahap sebelumnya.

Proses pemeriksaan terhadap hasil akhir tahap analisis. Bila terdapat kesalahan maka kembali ke tahap awal analisis bila hasilnya benar maka akan dijadikan input tahap perancangan UA.

1. 2. Tahap Perancangan

Gambar 1.2: Tahap Perancangan UA

Keterangan :

* Perancangan kelas, asosiasi, metode dan atribut

Pada tahap ini dilakukan perancangan dan pemeriksaan atribut, method dan visibilitasnya terhadap kelas-kelas yang telah teridentifikasi.

* Menyaring (Memeriksa) UML Class Diagram

Proses menyaring diagram kelas mulai dari nama kelas, asosiasi, atribut serta method-nya. Tahap ini difokuskan pada penggambaran method yang ada dengan activity diagram.

* Perancangan Layer Akses dan Layer Antarmuka

Proses merancang Layer akses dan Graphic User Interface (GUI) berdasarkan pada class diagram yang telah dirancang sebelumnya.

* Pengujian

Proses terakhir dari perancangan sistem adalah melakukan pengujian terhadap sistem. Apakah telah memenuhi kebutuhan atau masih terdapat kekurangan. Bila masih ada kekurangan maka dilakukan perbaikan.

SISTEM BASIS DATA

Tujuan Umum:

Tujuan umum dari penyampaian mata kuliah ini adalah membentuk dan menumbuhkan :
pengetahuan mengenai konsep basis data, model ER dan model relasional, serta proses perancangan basis data
kemampuan menangani operasi pada basis data operasional



Tujuan Khusus:

Pada akhir kuliah sistem basis data ini peserta kuliah diharapkan mampu :
memahami konsep yang melatarbelakangi perancangan basis data dengan model ER dan relasional
melakukan perancangan dan implementasi basis data dengan model ER dan relasional
melakukan penanganan operasi terhadap basis data operasional



Lingkup Bahasan:

Overview Basis Data, mencakup sejarah dan motivasi sistem basis data, komponen sistem basis data,
fungsi sistem manajemen basis data, arsitektur basis data dan independensi data, serta penggunaan bahasa query

Pemodelan Data, mencakup kategorisasi model data, model data konseptual (model ER), model berorientasi objek,
dan model relasional

Model Entity-Relationship, mencakup studi kasus dan penjelasan komponen-komponen diagram ER
Basis data relasional, mencakup pemetaan skema konseptual ke skema relasional, integritas entitas dan pengacuan,
operasi aljabar relasional, operasi kalkulus relasional berbasis tupel, serta operasi kalkulus relasional berbasis domain

Bahasa query, mencakup pengantar SQL, bahasa pendefinisian data, bahasa pemanipulasian data (modifikasi dan seleksi),
serta bahasa query lain

Perancangan basis data relasional, mencakup functional dependency (FD), normalisasi (1NF, 2NF, 3NF, BCNF)



Materi
Terminologi Dan Konsep Basis Data

Hirarki data

Konsep DBMS

Pemanfaatan ilmu basisdata

Abstraksi data

Model basis data

Model ER

Normalisasi

Perancangan basisdata

Studi kasus








Terminologi Dan Konsep Basis Data
Basis data terdiri dari 2 kata, yaitu basis & data. Basis dapat diartikan sebagai markas / gudang, tempat berkumpul.

Sedangkan data adalah fakta yang mewakili suatu objek seperti manusia, barang, hewan peristiwa, keadaan dan sebagainya,

yang direkam dalam bentuk angka, huruf simbol, teks gambar, bunyi atau kombinasinya.




Basis data sendiri dapat di definisikan dalam sejumlah sudut pandang seperti :

himpunan kelompok data / arsip yang saling berhubungan yang diorganisasi sedemikian rupa agar kelak dapat dimanfaatkan kembali dengan cepat & mudah.
Kumpulan data yang saling berhubungan yang disimpan secara bersama sedemikian rupa dan tanpa pengulangan/ penumpukan (redundansi),
untuk memenuhi berbagai kebutuhan.

Kumpulan file/ tabel /arsip yang saling berhubungan yang disimpan dalam media penyimpanan elektronis.













Basis data





Basis data dan lemari arsip sesungguhnya memiliki prinsip kerja dan tujuan yang sama. Prinsip utamanya adalah pengaturan data/arsip.

Dan tujuan utamanya adalah kemudahan dan kecepatan dalam pengambilan kembali data/ arsip.

Perbedaannya hanya terletak pada media penyimpanan yang digunakan . jika lemari arsip menggunakan lemari sebagai media penyimpanannya,

maka basisdata mnenggunakan media penyimpanan elektronis seperti disk (disket, harddisk).




Yang perlu diingat adalah bahwa tidak semua bentuk penyimpanan data secara elektronis bisa disebut basis data. Yang sangat ditonjolkan

dalam basisdata adalah pengaturan/pemilaha/pengelompokkan/pengorganisasian data yang akan kita simpan sesuai fungsi/jenisnya.

Pemilahan/ pengelompokan ini dapat berbentuk sejumlah file/ tabel terpisah atau dalam bentuk pendefinisian kolom-kolom/field-field data dalam setiap file/tabel.




Tujuan dibangunnya basis data adalah sebagai berikut :




Kecepatan & kemudahan (speed)

Dgn memanfaatkan basis data, memungkinkan kita untuk dapat menyimpan data atau melakukan perubahan/ manipulasi terhadap data

atau menampilkan kembali data tersebut secara lebih cepat & mudah.




Efisiensi ruang penyimpanan (space)

Karena keterkaitan yang erat antara kelompok data dalam sebuah basisdata,maka redundansi (pengulangan) pasti akan selalu ada,

sehingga akan memperbesar ruang penyimpanan. Dengan basisdata, efisiensi ruang penyimpanan dapat dilakukan dengan menerapkan

sejumlah pengkodean, atau dengan membuat relasi-relasi antar kelompok data yang saling berhubungan.




Keakuratan (accuracy)

Pengkodean atau pembentukan relasi antar data bersama dengan penerapan aturan/batasan (constraint), dmain data,

keunikan data, dsb, yang secara ketat dapat diterapkan dalam sebuah basis data, sangat berguna untuk menekan ketidak akuratan penyimpanan data.




Ketersediaan (availability)

Dengan pemanfaatan jaringan komputer, maka data yang berada di suatu lokasi/cabang dapat juga diakses (tersedia/available) bagi lokasi/cabang lain.




Kelengkapan (completeness)

Kelengkapan data yang disimpan dalam sebuah database bersifat relatif, bisa jadi saat ini dianggap sudah lengkap,

tetapi belum tentu pada suatu saat dianggap lengkap. Untuk mengakomodasi kelengkapan data, seperti




Keamanan (security)

aspek keamanan dapat diterapkan dengan ketat, dengan begitu kita dapat menentukan pemakai basis data serta obyek-obyek didalamnya ,

serta jenis-jenis operasi apa saja yang boleh dilakukannya.




Kebersamaan pemakaian (sharability)

Basis data yang dikelola dengan aplikasi multi user dapat memenuhi kebutuhan ini.




Alasan mengapa mempelajari basisdata :

perpindahan dari komputasi ke informasi
himpunan elemen data semakin banyak dan beragam
perpustakaan digital. Video interaktif
kebutuhan untuk memperluas DBMS
DBMS mencakup bidang ilmu lain
System operasi, bahasa pemrograman, teori komputasi, AI, logika, multimedia.



Operasi dasar pembuatan Basis data :

Pembuatan Basis Data (Create Database)
Yang identik dengan pembuatan lemari arsip yang baru.

Penghapusan Basis Data (Drop Database)
Yang identik dengan perusakan lemari arsip (sekaligus beserta isinya, jika ada)

Pembuatan File/Table baru ke suatu basis data (Create Table)
Yang identik dengan penambahan map arsip baru ke sebuah lemari arsip yang telah ada.




Penghapusan File/Table dari suatu basis data (Drop Table)
Yang identik dengan perusakan map arsip lama yang ada di sebuah lemari arsip.

Penambahan data baru ke suatu file/table di sebuah basis data (insert)
Identik dengan penambahan lembaran arsip baru kesebuah map arsip.

Pengambilan data dari sebuah file/table (Retrieve/Search)
Identik dengan pencarian lembaran arsip dari sebuah map arsip.

Pengubahan data dari sebuah file/table (Update)
Identik dengan perbaikan isi lembaran arsip yang ada di sebuah map arsip.

Penghapusan data dari sebuah file/table (Delete)
Identik dengan penghapusan sebuah lembaran arsip yang ada di sebuah map arsip.




Hirarki Data
Berdasarkan tingkat kompleksitas nilai data, tingkatan data dapat disusun kedalam sebuah hirarki, mulai dari yang paling sederhana hingga yang paling komplek.

basis data, merupakan sekumpulan dari bermacam-macam tipe record yang memiliki hubungan antar record.
berkas/file, merupakan sekumpulan rekaman data yang berkaitan denngan suatu objek.
record , merupakan sekumpulan field/atribut/data item yang saling berhubungan terhadap obyek tertentu
fixed length record, semua field dalam record memiliki ukuran yang tetap.
Variabel length record, field-field dalam record dapat memiliki ukuran berbeda (metode penandaan yang digunakan adalah :
end of record marker, indikator panjang, dan tabel posisi record)

field/atribut/data item, merupakan unit terkecil yang disebut data,yang tidak dapat dipecah lagi menjadi unit lain yang bermakna.
fixed length field, memiliki ukuran yang tetap.
variabel length field, field-field dalam record dapat memiliki ukuran berbeda.
byte, adalah bagian terkecil yang dialamatkan dalam memori.
byte mrupakan sekumpulan bit yang secara konvensional terdiri atas kombinasi delapan bit yang menyatakan sebuah karakter dalam memori (I byte= I karakter)

bit, adalah sistem binner yang terdiri atas dua macam nilai, yaitu 0 dan 1. sistem binner merupakan dasar yang dapat digunakan untuk komunikasi antara manusia dan mesin, yang merupakan serangkaian komponen elektronik dan hanya dapat membedakan 2 macam keadaan, yaitu ada tegangan dan tidak ada tegangan yang masuk ke rangkaian tersebut.



Konsep DBMS (database management system)
Database Management System (DBMS) merupakan paket program (Software) yang dibuat agar memudahkan dan mengefisienkan pemasukan, pengeditan, penghapusan dan pengambilan informasi terhadap database.

Software yang tergolong kedalam DBMS antara lain, Microsoft SQL, MySQL, Oracle, MS. Access, dan lain-lain




Komponen utama DBMS :

perangkat keras
berupa komputer dan bagian-bagian didalamnya, seperti prosesor, memori & harddisk. Komponen inilah yang melakukan pemrosesan dan juga untuk menyimpan basis data.

basisdata
sebuah DBMS dapat memiliki beberapa basisdata, setiap basisdata dapat berisi sejumlah obyek basisdata (file,tabel,indeks dsb). Disamping berisi data,setiap basisdata juga menyimpan definisi struktur (baik untuk basisdata maupun obyek-obyeknya secara detail).

perangkat lunak
perangkat lunak ini terdiri dari sistem operasi dan perangkat lunak/program pengelola basisdata. Perangkat lunak inilah yang akan menentukan bagaimana data diorganisasi,disimpan, diubah dan diambil kembali. Ia juga menerapkan mekanisme pengamanan data, pemakaian data secara bersama, pemaksaan keakuratan/konsistensi data, dsb.

Contoh perangkat lunak DBMS : MS access, SQL Server, Oracle dsb.

pengguna/user
pengguna dapat digolongkan menjadi 3 :

pengguna akhir / end user.
Dapat dibagi menjadi 2 :

pengguna aplikasi : adalah orang yang mengoperasikan program aplikasi yang dibuat oleh pemrogram aplikasi.
pengguna interaktif : adalah orang yg dpt memberikan perintah-perintah pada antar muka basisdata, misalnya SELECT, INSERT dsb.
pemrogram aplikasi
adalah orang yang membuat program aplikasi yang menggunakan basisdata.

administrator database / DBS (database administrator)
adalah orang yang bertanggungjawab terhadap pengelolaan basisdata.

Tugas DBA :

mendefinisikan basisdata
menetukan isi basisdata
menentukan sekuritas basisdata












Pemanfaaatan Ilmu Basis Data
Bidang Fungsional :

Kepegawaian
Pergudangan (inventory)
Akuntansi
Reservasi
Layanan Pelanggan
Bentuk Perusahan :

Perbankan
Rumah Sakit
Produsen Barang
Sekolah
Telekomunikasi



Abstraksi Data
Salah satu tujuan dari DBMS adalah untuk menyediakan fasilitas/antarmuka (interface) kepada user.untuk itu system tersebut akan menyembunyikan detail tentang bagaimana data disimpan dan dipelihara, sehingga data yang terlihatoleh user sebenarnya berbeda dengan yang tersimpan secara fisik.

Abstraksi data merupakan tingkatan-tingkatan pengguna dalam memandang bagaimana sebenarnya data diolah dalam sebuah sistem database sehingga menyerupai kondisi yang sebenarnya dihadapi oleh pengguna sehari-hari.. Sebuah DBMS seringkali menyembunyikan detail tentang bagaimana sebuah data disimpan dan dipelihara (diolah) dalam sebuah sistem database, dengan tujuan untuk memudahkan pengguna dalam menggunakan DBMS tersebut. Karena itu seringkali data yang terlihat oleh pemakai sebelumnya berbeda dengan yang tersimpan secara fisik.









Terdapat 3 level abstraksi :

Level Fisik (Physical Level)
Lapis fisik merupakan lapis terendah, lapis ini menjelaskan bagaimana (how) data sesungguhnya disimpan. Pada lapis inilah struktur data dijabarkan secara rinci.

Level Logik / Konseptual (Conceptual Level)
Lapis konseptual lebih tinggi dari lapis fisik. Lapis ini menjabarkan data apa (what) saja yang sesungguhnya disimpan pada basisdata, dan juga menjabarkan hubungan-hubungan antardata secara keseluruhan. Seorang pengguna dalam level ini dapat mengetahui bahwa data mahasiswa disimpan pada tabel mahasiswa, tabel krs, tabel transkrip dan lain sebagainya. Level ini biasa dipakai oleh DBA.

Level Penampakan/pandangan (View Level)
Lapis pandangan merupakan lapis tertinggi pada abstraksi data. Pada lapis ini pengguna hanya mengenal struktur data yang sederhana, yang berorientasi pada kebutuhan pengguna. Data yang dikenal oleh masing-masing pengguna bisa berbeda-beda dan barangkali hanya mencakup sebagian dari basis data. Misalnya: Bagian keuangan hanya membutuhkan data keuangan, jadi yang digambarkan hanya pandangan terhadap data keuangan saja, begitu juga dengan bagian akuntansi, hanya membutuhkan data akuntansi saja. Jadi tidak semua pengguna database membutuhkan seluruh informasi yang terdapat dalam database tersebut.




Sebagai gambaran , misalnya terdapat struktur data bertipe record seperti berikut :



Pegawai = RECORD

Nama : STRING;

Alamat : STRING;

Bagian : STRING;

Gaji : LongInt;

End:




Pada contoh ini record pegawai berisi 4 buah field (nama, alamat, bagian, gaji ). Setiap field memiliki nama, dan setiap nama memiliki tipe data.

Pada level fisik, pegawai dapat dijabarkan sebagai blok data yang terletak pada lokasi berurutan (satuan byte). Pada lapis konseptual masing-masing record dijabarkan dengan definisi tipe data . pada lapis view, user tertentu hana boleh mengakses data tertentu, contohnya, seorang yang menangani penggajian berhak mengetahui gaji seseorang bahkan mengubahnya, tetapi orang yang bekerja di bagian lain tentu tidak boleh melihatnya.













Model Basis Data
Model database adalah suatu konsep yang terintegrasi dalam menggambarkan hubungan (relationships) antar data dan batasan-batasan (constraint) data dalam suatu sistem database. Model data yang paling umum, berdasarkan pada bagaimana hubungan antar record dalam database (Record Based Data Models), terdapat tiga jenis,

yaitu :




a. Model Database Hirarki (Hierarchical Database Model)

Model hirarkis biasa disebut model pohon, karena menyerupai pohon yang dibalik. Model ini menggunakan pola hubungan orangtua-anak






b. Model Database Jaringan (Network Database Model)









c. Model Database Relasi (Relational Database Model)

Model Relasional merupakan model yang paling sederhana sehingga mudah digunakan dan dipahami oleh pengguna. Model ini menggunakan sekumpulan tabel berdimensi dua ( yang disebut relasi atau tabel ), dengan masing-masing relasi tersusun atas tupel atau baris dan atribut. DBMS yang bermodelkan relasional biasa disebut RDBMS (Relational Data Base Management System). Model database ini dikemukakan pertamakali oleh EF codd, seorang pakar basisdata. Model ini sering disebut juga dengan database relasi.




Model database hirarki dan jaringan merupakan model database yang tidak banyak lagi dipakai saat ini, karena adanya berbagai kelemahan dan hanya cocok untuk struktur hirarki dan jaringan saja. Artinya tidak mengakomodir untuk berbagai macam jenis persoalan dalam suatu sistem database.




Model database relasi merupakan model database yang paling banyak digunakan saat ini, karena paling sederhana dan mudah digunakan serta yang paling penting adalah kemampuannya dalam mengakomodasi berbagai kebutuhan pengelolaan database. Sebuah database dalam model ini disusun dalam bentuk tabel dua dimensi yang terdiri dari baris (record) dan kolom (field), pertemuan antara baris dengan kolom disebut item data (data value), table-tabel yang ada di hubungkan (relationship) sedemikian rupa menggunakan field-field kunci (Key field) sehingga dapat meminimalkan duplikasi data.




Tingkatan Data Dalam Database Relasi

Dalam suatu sistem database relasi, data yang tersimpan dalam DBMS mempunyai tingkatan-tingkatan, sebagai berikut :

• Karakter (Characters)

Merupakan bagian terkecil dalam database, dapat berupa karakter numerik (angka 0 s.d 9), huruf ( A - Z, a - z) ataupun karakter-karakter khusus, seperti *, &. %, # dan lain-lain.

• Field atau Attribute

Merupakan bagian dari record yang menunjukkan suatu item data yang sejenis, Misalnya : field nama, file NIM dan lain sebagainya. Setiap field harus mempunyai nama dan tipe data tertentu. Isi dari field di sebut Data Value. Dalam table database, field ini disebut juga kolom.

Record atau Tupple

Tuple/Record adalah kumpulan data value dari attributee yang berkaitan sehingga dapat menjelaskan sebuah entity secara lengkap. Misal : Record entity mahasiswa adalah kumpulan data value dari field nobp, nama, jurusan dan alamat per-barisnya. Dalam tabel database, Record disebut juga baris.

• Table/Entity

Entity merupakan sesuatu yang dapat diidentifikasi dari suatu sistem database, bisa berupa objek, orang, tempat, kejadian atau konsep yang informasinya akan disimpan di database. Misal. Pada sistem database akademik, yang menjadi entity adalah, mahasiswa, dosen, matakuliah dan lain-lain. Dalam aplikasi nantinya, penggunaan istilah Entity sering di samakan dengan istilah Tabel. (Entity = table). Disebut tabel, karena dalam merepresentasikan datanya di atur dalam bentuk baris dan kolom. Baris mewakili 1 record dan kolom mewakili 1 field. Dalam sistem database tradisional, entity/table ini disebut juga dengan file.

• Database

Kumpulan dari tabel-tabel yang saling berelasi, disusun secara logis, sehingga menghasilkan informasi yang bernilai guna dalam proses pengambilan keputusan.




Ada beberapa sifat yang melekat pada suatu tabel :

• Tidak boleh ada record yang sama (kembar)

• Urutan record tidak terlalu penting, karena data dalam record dapat diurut sesuai dengan kebutuhan.

• Setiap field harus mepunyai nama yang unik (tidak boleh ada yang sama).

• Setiap field mesti mempunyai tipe data dan karakteristik tertentu




Contoh produk DBMS terkenal yang menggunakan model relasional antara lain adalah :

1. DB2 (IBM)
2. Rdb/VMS (Digital Equipment Corporation)
3. Oracle (Oracle Corporation)
4. Informix (Informix Corporation)
5. Ingres (ASK Group Inc)
6. Sybase (Sybase Inc)




Di lingkungan PC, produk-produk berbasis relasional yang cukup terkenal antara lain adalah :

1. Keluarga R:Base (Microrim Corp) antara lain berupa R:Base 5000
2. Keluarga dBase (Ashton-Tate, sekarang bagian dari Borland International), antara lain dbase III Plus, dBase IV, serta Visual dBase
3. Microsoft SQL ( Microsoft Corporation)
4. Visual FoxPro (Microsoft Corporation)




MACAM-MACAM PERINTAH DATA BASE

1. Bahasa Definisi Data (Data Definition Language/ DDL)

DDL adalah perintah-perintah yang biasa digunakan oleh administrator basis data (DBA) utnuk mendefinisikan skema ke DBMS. Skema adalah deskripsi lengkap tentang struktur medan, rekaman, dan hubungan data pada basis data
Index merupakan suatu mekanisme yang lazim digunakan pada basis data, yang memungkinkan pengambilan data dapat dilakukan dengan cepat.

DDL Digunakan untuk mespesifikasikan struktur/skema basis data yang menggambarkan/mewakili desain basis data secara keseluruhan.

Hasil kompilasi perintah DDL adalah kamus data (File yang berisi metadata (data yang mendeskripsikan data sesungguhnya).

Struktur penyimpan dan metode akses yang digunakan oleh sistem basis data disebut dengan data storage and definition language.




2. Bahasa Manipulasi Data (Data Manipulation laguage/ DML)

DML adalah perintah-perintah yang digunakan untuk mengubah, manipulasi dan mengambil data pada basis data. Tindakan seperti menghapus, mengubah, dan mengambil data menjadi bagian dari DML.

DML pada dasarnya dibagi menjadi dua :




- Prosedural, yang menuntut pengguna menentukan data apa saja yang diperlukan dan bagaimana cara mendapatkannya.

- Nonprosedural, yang menuntut pengguna menentukan data apa saja yang diperlukan, tetapi tidak perlu menyebutkan cara mendapatkannya.




3. DQL ( Data Query Language)

Query sesungguhnya berarti pertanyaan atau permintaan. Istilah ini tetap dipertahankan dalam bentuk asli, karena telah populer di kalangan pengguna DBMS di Indonesia




Model Entity-Relationship (ER)

Model Entity-Relationship adalah model data konseptual tingkat tinggi untuk perancangan basis data. Model data konseptual adalah himpunan konsep yang mendeskripsikan struktur basis data, transaksi pengambilan dan pembaruan basis data.


Model ER adalah data konseptual tak tergantung DBMS dan platform perangkat keras tertentu. Model ER dikemukakan oleh Chen [1976]. Sejak itu, telah memperoleh banyak perhatian dan perluasan.


Model ER adalah persepsi terhadap dunia nyata sebagai terdiri objek-objek dasar yang disebut entitas dan keterhubungan (relationship) antar entitas-entitas itu.


Konsep paling dasar di model ER adalah entitas, relationship dan atribut.

Komponen-komponen utama model ER adalah:


a. Entitas (entity), Entitas memodelkan objek-objek yang berada diperusahaan/lingkungan.
b. Relationship. Relationship memodelkan koneksi/hubungan di antara entitas-entitas.
c. Atribut-atribut (properi-properti), memodelkan properti-properti dari entitas dan relationship.
d. Konstrain-konstrain (batasan-batasan) integritas, konstrain-konstrain ketentuan validitas.




Entitas (Entity) dan Himpunan Entitas (Entitas Sets)


Entitas merupakan individu yang mewakili sesuatu yang nyata (eksistensinya) dan dapat dibedakan dari sesuatu yang lain. Sebuah kursi yang kita duduki, seseorang yang menjadi pegawai di sebuah perusahaan dan sebuah mobil yang melintas di depan kita adalah entitas.


Sekelompok entitas yang sejenis dan berada dalam lingkup yang sama membentuk sebuah himpunan entitas (entity sets). Sederhananya, entitas menunjuk pada individu suatu objek, sedang himpunan entitas menunjuk pada rumpun (family) dari individu tersebut.


Seorang pasien, misalnya akan dimasukkan dalam himpunan entitas pasien. Sedang seorang dokter akan ditempatkan dalam himpunan entitas dokter.


Dalam berbagai pembahasan/literature, penyebutan himpunan entitas (yang kurang praktis) ini seringkali digantikan dengan sebutan entitas saja.


Karena itu sering ditemui, penggunaan istilah entitas (entity) di sebuah literature sebenarnya menunjuk pada himpunan entitas.

Kunci Entitas


Sebagaimana model relasional, adalah penting dan berguna untuk memasukkan kunci yang diasosiasikan dengan himpunan entitas. Kunci pada himpunan entitas S, adalah himpunan atribut A. Sehingga tidak ada dua entitas di S yang mempunyai nilai sama untuk tiap atribut di A dan tidak ada subset di A yang dapat menjadi kunci di S, dengan demikian kunci mempunyai property minimal.




Atribut (Atributes/Properties)


Setiap entitas pasti memiliki atribut yang mendeskripsikan karakteristik (property) dari entitas tersebut.


Penentuan / pemilihan atribut-atribut yang relevan bagi sebuah entitas merupakan hal penting lainnya dalam pembentukan model ER. Contoh : nim, nama, alamat, kode.







Relasi (Relationship) dan Himpunan Relasi (Relationship Sets)


Relasi menunjukkan adanya hubungan di antara sejumlah entitas yang berasal dari himpunan entitas yang berbeda.



Misalnya, entitas seorang mahasiwa dengan

nim = ‘980001’ dan

nama_mhs = ‘Ali Akbar’ (yang ada di himpunan entitas Mahasiswa)


mempunyai relasi dengan entitas sebuah mata kuliah dengan


kode_kul=’IF-110’ dan

nama_kul=’Struktur Data’.


Relasi diantara kedua entitas tadi mengandung arti bahwa mahasiswa tersebut sedang mengambil/mempelajari mata kuliah tersebut di sebuah perguruan tinggi yang ditinjau.


Kumpulan semua relasi diantara entitas-entitas yang terdapat pada himpunan entitas-himpuan entitas tersebut membentuk himpunan relasi (relationship sets).

Sebagaimana istilah himpunan entitas yang banyak sekali disingkat menjadi entitas, istilah himpunan relasi jarang sekali digunakan dan lebih sering disingkat dengan istilah relasi saja.


Kardinalitas/derajat Relasi


Kardinalitas Relasi menunjukkan jumlah maksimum entitas yang dapat berelasi dengan entitas pada himpunan entitas yang lain. Kardinalitas relasi merujuk kepada hubungan maksimum yang terjadi dari himpunan entitas yang satu ke himpunan entitas yang lain dan begitu juga sebaliknya.


Kardinalitas di antara dua himpunan entitas (misalnya A dan B) dapat berupa :


a. Satu ke satu (One to One),

setiap entitas pada himpunan entitas A berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas begitu juga sebaliknya setiap entitas pada himpunan entitas B berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas A.


b. Satu ke Banyak (one to many),

setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B,
tetapi tidak sebaliknya, dimana setiap entitas pada himpunan entitas B berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas A.




c. Banyak ke Satu (Many to One),

setiap entitas pada himpunan entitas A berhubungan dengan paling banyak dengan satu entitas pada himpunan entitas B, tetapi tidak sebaliknya, dimana setiap entitas pada himpunan entitas A berhubungan dengan paling banyak satu entitas pada himpunan entitas B.


d. Banyak ke Banyak (Many to Many)

setiap entitas pada himpunan entitas A dapat berhubungan dengan banyak entitas pada himpunan entitas B,
demikian juga sebaliknya, di mana setiap entitas pada himpunan entitas B dapat berhubungan dengan banyak entitas pada himpunan entitas A.


Diagram Entity-Relationship (ER)


Penggambaran Model ER secara sistematis dilakukan melalui diagram ER. Notasi-notasi simbolik di dalam Diagram ER yang dapat digunakan adalah:

Persegi panjang, menyatakan Himpunan Entitas.
Lingkaran/Elips, menyatakan atribut (Atribut yang berfungsi sebagai key digaris bawahi).
Belah ketupat, menyatakan Himpunan Relasi.
Garis, sebagai penghubung antara Himpunan Relasi dengan Himpunan Entitas dan Himpunan Entitas dengan atributnya.
Kardinalitas Relasi dapat dinyatakan dengan banyaknya garis cabang atau dengan pemakaian angka (1 dan 1 untuk relasi one to one, 1 dan N untuk relasi one to many atau N dan N untuk relasi many to many).


Contoh diagram ER :





Tahap Pembuatan Diagram ER


Diagram ER selalu dibuat secara bertahap. Paling tidak ada dua kelompok penahapan yang biasa ditempuh di dalam pembuatan diagram ER, yaitu :


a. Tahap pembuatan Diagram ER awal (preliminary design). Yaitu :




Mengidentifikasi dan menetapkan seluruh entity yang terlibat dalam sistem database tersebut.
Menentukan attribute-attribute atau field dari masing-masing entity beserta kunci (key)-nya.
Menentukan attribute dari suatu entitas sangat menentukan baik atau tidaknya sistem database yang dirancang, karena attribute ini sangat menentukan nantinya dalam proses relasi. Attribute merupakan ciri khas yang melekat pada suatu entity, misalnya attribute pada mahasiswa dapat berupa nobp, nama, tempat lahir, tanggal lahir, alamat, nama orang tua, pekerjaan orang tua dan lain-lain. Dari sekian banyak kemungkinan attribute yang ada pada entity mahasiswa, kita dapat menggunakan hanya yang perlu saja. Setelah menentukan attributenya selanjutnya adalah menentukan field kunci. Field kunci adalah penanda attribute tersebut sehingga bisa digunakan untuk relasi nantinya dan field kunci ini harus bersifat unik. Misalnya pada entity mahasiswa, attribute nobp bisa dijadikan field kunci, karena bersifat unik dan tidak ada mahasiswa yang mempunyai nobp sama.




Mengidentifkasi dan menetapkan seluruh himpunan relasi diantara himpunan-himpunan entity yang ada beserta kunci tamu (foreign key)- nya.
Setelah menentukan entity dan attribute beserta field kuncinya, maka selanjutnya adalah menentukan entity yang terbentuk akibat adanya relasi antar entity. Misalnya antara entity mahasiswa dengan entity dosen, terjadi suatu hubungan proses mengajar, maka proses mengajar ini merupakan entity baru. Entity mengajar ini harus kita tentukan juga attribute yang melekat padanya beserta kunci tamu (foreign key). Kunci tamu adalah field kunci utama pada tabel lain, dan field tersebut digunakan juga pada tabel yang satu lagi. Misalnya nobp adalah

field kunci dari entity mahasiswa, pada entity mengajar terdapat juga attribute NoBP, maka keberadaan attribute nobp pada entity mengajar disebut sebagai kunci tamu. Proses menentukan hubungan antar entity juga sangat menentukan kualitas system database yang dirancang.




Menentukan derajat relasi untuk setiap himpunan relasi.
Setelah semua entity dan attribute yang dibutuhkan terbentuk, maka selanjutnya adalah menentukan derajat relasi antar entity tersebut, apakah satu kesatu, satu ke banyak atau sebaliknya, atau banyak ke banyak. Berhati-hatilah dalam menentukan derajat relasi ini, karena nantinya akan berhubungan dengan proses query terhadap data

Melengkapi himpunan entitas dan himpunan relasi dengan atribut-atribut deskriptif (non key).



Jenis-Jenis Kunci (Key)

• Candidat Key

Sebuah attribute atau lebih yang secara unit mengidentifikasi sebuat record, disebut candidate key. Attribute ini mempunyai nilai yang unik pada hampir setiap recordnya. Fungsi dari candidate key ini adalah sebagai calon primary key.

Contoh candidate-key :






• Primary Key

Salah satu atrribut dari candidat key dapat dipilih menjadi primary key dengan 3 kriteria sbb :




Key tersebut lebih natural untuk dijadikan acuan
Key tersebut lebih sederhana
Key tersebut cukup uniqe



• Foreign Key

Jika sebuah primary key terhubungan ke table/entity lain, maka keberadaan primary key pada entity tersebut di sebut sebagai foreign key. Misal : Primary Key KodeDosen dari entity Dosen digunakan juga pada field entity KRS, maka keberadaan field KodeDosen pada entity KRS disebut sebagai foreign key.

• Alternate Key

Setiap atribut dari candidate key yang tidak terpilih sebagai primary key akan dinamakan alternate key. Pada contoh sebelumnya bila untuk primary key dipilih ID_Cus maka alternate key nya adalah No.of Pay






b. Tahap optimasi Diagram ER (final design).




Normalisasi
Proses normalisasi adalah proses untuk memperoleh properti-properti skema relasi yang bagus menjadi bentuk normal lebih tinggi sehingga syarat-syarat dibawah ini terpenuhi:

Mengoptimalisasi redudansi (pengulangan data yang tidak perlu). Redudansi tidak bisa dihilangkan sama sekali karena berguna untuk integritas referensial, tetapi redudansi bisa dioptimalisasi. Untuk jumlah data yang tidak terlalu banyak mungkin tidak terlalu berpengaruh dalam hal penggunaan harddisk. Tapi bayangkan jika ada ribuan, bahkan jutaan redudansi, mungkin akan sangat berpengaruh pada penggunaan ruang.
Menghilangkan anomali. Anomali pada dasarnya adalah ketidak-konsistenan (inkonsistensi). Misalkan ada pergantian nama dari Bank Perkasa menjadi Bank Perkasa Utama sebanyak 4 record. Jika pergantian nama hanya dilakukan pada salah satu record saja, maka terjadi ketidak-konsistenan yaitu satu nomor bank berrelasi dengan 2 nama bank yang berbeda.



Dekomposisi tabel dapat mengurangi redudansi yang ada dan menghilangkan anomali.

Perancangan melalui proses normalisasi mempunyai keuntungan-keuntungan sebagai berikut :


a. Meminimalkan ukuran penyimpanan yang diperlukan untuk penyimpanan data.

b. Meminimalkan resiko inkonsistensi data pada basis data.
c. Meminimalkan kemungkinan anomaly pembaruan.
d. Memaksimalkan stabilitas struktur data.

Bentuk Normal

Tujuan proses normalisasi adalah mengkonversi relasi menjadi bentuk normal lebih tinggi. Terdapat beragam tingkat bentuk normal, yaitu :

a. Bentuk normal pertama (1NF)
b. Bentuk normal kedua (2NF)
c. Bentuk normal ketiga (3NF)
d. Bentuk normal Boyce-Codd (BCNF)
e. Bentuk normal keempat (4NF)
f. Bentuk normal kelima (5NF)



Codd mendefinisikan bentuk normal pertama, kedua dan ketiga di makalah (Codd, 1970). Bentuk normal ketiga kemudian diperbaiki sehingga mempunyai bentuk normal yang lebih kuat yaitu BCNF (Codd, 1974). Fagin memperkenalkan bentuk normal keempat (Fagin, 1977), kemudian Fagin juga memperkenalkan bentuk normal kelima (Fagin, 1979).


Bentuk normal pertama untuk menghilangkan atribut bernilai jamak. Bentuk normal kedua untuk menghilangkan kebergantungan parsial. Bentuk normal ketiga untuk menghilangkan kebergantungan transitif. Bentuk normal Boyce-Codd untuk menghilangkan anomaly tersisa disebabkan kebergantungan fungsional. Bentuk normal keempat untuk menghilangkan kebergantungan nilai jamak. Bentuk normal kelima untuk menghilangkan anomaly tersisa.


Tiga bentuk normal pertama berkaitan dengan kebergantungan fungsional. Sementara itu bentuk keempat dan kelima berkaitan dengan redudansi yang disebabkan kebergantungan banyak nilai (multi-valued dependencies).




Bentuk Normal Pertama


Bentuk normal pertama adalah ekivalen dengan definisi model relasional. Relasi adalah bentuk normal pertama (1NF) jika semua nilai atributnya adalah sederhana (bukan komposit).

Syarat :

Tidak ada set atribut yang berulang atau bernilai ganda.
Telah ditentukannya primary key untuk tabel atau relasi.
Tiap atribut hanya memiliki satu pengertian.
Tiap atribut yang dapat memiiki banyak nilai sebenarnya menggambarkan entitas atau relasi yang terpisah.

Bentuk Normal Kedua

Syarat :

Bentuk data telah memenuhi kriteria bentuk normal ke satu.
Atribut bukan kunci(non-key attribute) haruslah memiliki ketergantungan fungsional sepenuhnya pada primary key
Relasi pada bentuk normal kedua harus tidak menyimpan fakta-fakta mengenai bagian kunci relasi. Bentuk normal kedua menghilangkan kebergantungan parsial dan masih memiliki anomali-anomali yang secara praktis tidak dapat diterima.


Bentuk Normal Ketiga

Syarat :

Bentuk data telah memenuhi kriteria bentuk normal ke dua.
Atribut bukan kunci(non-key attribute) tidak boleh memiliki ketergantungan fungsional terhadap atribut bukan kunci lainnya. Seluruh atribut bukan kunci pada suatu relasi hanya memiliki ketergantungan fungsional terhadap primary key di relasi itu saja.

Bentuk normal ketiga menghilangkan kebergantungan transitif, awalnya bentuk normal ketiga dipikir sebagai bentuk normal puncak/paling akhir. Namun kemudian dapat ditemukan bentuk normal lebih kuat yaitu bentuk normal Boyce-Codd.


Bentuk Normal Boyce-Codd (BCNF)


BCNF memiliki ketentuan yaitu masing-masing atribut utama bergantung fungsional penuh pada masing-masing kunci dimana kunci tersebut bukan bagiannya. Relasi adalah BCNF (optimal) jika setiap determinan atribut-atribut relasi adalah kunci relasi. Relasi adalah BCNF (optimal) jika kapanpun fakta-fakta disimpan mengenai beberapa atribut, maka atribut-atribut ini merupakan satu kunci relasi. BCNF dapat memiliki lebih dari satu kunci. Properti penting BCNF adalah relasi tidak memiliki informasi yang redundan.


Bentuk Normal Keempat


Relasi dalam bentuk normal keempat (4NF) jika relasi dalam BCNF dan tidak berisi kebergantungan banyak nilai. Untuk menghilangkan kebergantungan banyak nilai dari satu relasi, kita membagi relasi menjadi dua relasi baru. Masing – masing relasi berisi dua atribut yang mempunyai hubungan banyak nilai.


Bentuk Normal Kelima


Bentuk normal kelima (5NF) berurusan dengan properti yang disebut join tanpa adanya kehilangan informasi (lossless join). Bentuk normal kelima (5NF) juga disebut PJNF (projection-join normal form). Kasus-kasus ini sangat jarang muncul dan sulit untuk dideteksi secara praktis.




Contoh Normalisasi pada beberapa tingkatan.

Diberikan tabel Mahasiswa di bawah ini, akan dilakukan normalisasi sampai bentuk normal ke tiga

Model spiral

 Model spiral

Model spiral pada awalnya diusulkan oleh Boehm, adalah model proses perangkat lunak evolusioner yang merangkai sifat iteratif dari prototype dengan cara kontrol dan aspek sistematis model sequensial linier.


        Model iteratif ditandai dengan tingkah laku yang memungkinkan pengembang mengembangkan versi perangkat lunak yang lebih lengkap secara bertahap. Perangkat lunak dikembangkan dalam deretan pertambahan. Selama awal iterasi, rilis inkremantal bisa berupa model/prototype kertas, kemudian sedikit demi sedikit dihasilkan versi sistem yang lebih lengkap.


Tahapan-Tahapan Model Spiral


Model spiral dibagi menjadi enam wilayah tugas yaitu:
1. Komunikasi pelanggan  
    Yaitu tugas-tugas untuk membangun komunikasi antara pelanggan dan kebutuhankebutuhan yang diinginkan oleh pelanggan

2. Perencanaan
   Yaitu tugas-tugas untuk mendefinisikan sumber daya, ketepatan waktu, dan proyek
    informasi lain yg berhubungan.

3. Analisis Resiko
    Yaitu tugas-tugas yang dibutuhkan untuk menaksir resikomanajemen dan teknis.

4. Perekayasaan
    Yaitu tugas yang dibutuhkan untuk membangun satu atau lebih representasi dari
    apikasi tersebut.

5. Konstruksi dan peluncuran
    Yaitu tugas-tugas yang dibutuhkan untuk mengkonstruksi, menguji, memasang , dan
    memberi pelayanan kepada pemakai.

6. Evaluasi Pelanggan
    Yaitu tugas-tugas untuk mendapatkan umpan balik dari pelanggan.


Kelebihan dan Kelemahan Model Spiral


a. Kelebihan model Spiral :
   1. Dapat disesuaikan agar perangkat lunak bisa dipakai selama hidup perangkat lunak
       komputer.
   2. Lebih cocok untuk pengembangan sistem dan perangkat lunak skala besar
   3. Pengembang dan pemakai dapat lebih mudah memahami dan bereaksi terhadap
       resiko setiap tingkat evolusi karena perangkat lunak terus bekerja selama proses .
   4. Menggunakan prototipe sebagai mekanisme pengurangan resiko dan pada setiap
       keadaan di dalam evolusi produk.
   5. Tetap mengikuti langkah-langkah dalam siklus kehidupan klasik dan memasukkannya
       ke dalam kerangka kerja iteratif .
   6. Membutuhkan pertimbangan langsung terhadp resiko teknis sehingga mengurangi
       resiko sebelum menjadi permaslahan yang serius.


b. Kelemahan model Spiral :
   1. Sulit untuk menyakinkan pelanggan bahwa pendekatan evolusioner ini bisa dikontrol.
   2. Memerlukan penaksiran resiko yang masuk akal dan akan menjadi masalah yang
       serius jika resiko mayor tidak ditemukan dan diatur.
   3. Butuh waktu lama untuk menerapkan paradigma ini menuju kepastian yang absolut

Metode Prototype

Prototype

       Prototyping merupakan salah satu metode pengembangan perangat lunak yang banyak digunakan.
Dengan metode prototyping ini pengembang dan pelanggan dapat saling berinteraksi selama proses pembuatan sistem.
Seing terjadi seorang pelanggan hanya mendefinisikan secara umum apa yang dikehendakinya tanpa menyebutkan secara detal output apa saja yang dibutuhkan, pemrosesan dan data-data apa saja yang dibutuhkan. Sebaliknya disisi pengembang kurang memperhatikan efesiensi algoritma,  kemampuan sistem operasi dan interface yang menghubungkan manusia dan komputer.


       Untuk mengatasi ketidakserasian antara pelanggan dan pengembang , maka harus dibutuhakan kerjasama yanga baik diantara keduanya sehingga pengembang akan mengetahui dengan benar apa yang diinginkan pelanggan dengan tidak mengesampingkan segi-segi teknis dan pelanggan akan mengetahui proses-proses dalm menyelasaikan sistem yang diinginkan. Dengan demikian akan menghasilkan sistem sesuai dengan jadwal waktu penyelesaian yang telah ditentukan.


       Kunci agar model prototype ini berhasil dengan baik adalah dengan mendefinisikan aturan-aturan main pada saat awal, yaitu pelanggan dan pengembang harus setuju bahwa prototype dibangun untuk mendefinisikan kebutuhan. Prototype akan dihilangkan sebagian atau seluruhnya dan perangkat lunak aktual aktual direkayasa dengan kualitas dan implementasi yang sudah ditentukan


Tahapan-tahapan Prototyping


       Tahapan-tahapan dalam Prototyping adalah sebagai berikut:


       1. Pengumpulan kebutuhan

      Pelanggan dan pengembang bersama-sama mendefinisikan format seluruh perangkat lunak mengidentifikasikan semua kebutuhan, dan garis besar sistem yang akan dibuat.

       2. Membangun prototyping

           Membangun prototyping dengan membuat perancangan sementara yang berfokus pada penyaji  kepada pelanggan (misalnya dengan membuat input dan format output)

       3. Evaluasi protoptyping

           Evaluasi ini dilakukan oleh pelanggan apakah prototyping yang sudah dibangun sudah sesuai dengan keinginann pelanggan. Jika sudah sesuai maka langkah 4 akan diambil. Jika tidak prototyping direvisi dengan mengulangu langkah 1, 2 , dan 3.

       4. Mengkodekan sistem
             Dalam tahap ini prototyping yang sudah di sepakati diterjemahkan ke dalam bahasa pemrograman yang sesuai


       5. Menguji sistem

           Setelah sistem sudah menjadi suatu perangkat lunak yang siap pakai, harus dites dahulu sebelum digunakan. Pengujian ini dilakukan dengan White Box, Black Box, Basis Path, pengujian arsitektur dan lain-lain

       6. Evaluasi Sistem
           Pelanggan mengevaluasi apakah sistem yang sudah jadi sudah sesuai dengan yang diharapkan . Juka ya, langkah 7 dilakukan; jika tidak, ulangi langkah 4 dan 5.


       7. Menggunakan
 Perangkat lunak yang telah diuji dan diterima pelanggan siap untuk digunakan .

Keunggulan prototyping adalah:
       1. Adanya komunikasi yang baik antara pengembang dan pelanggan
       2. Pengembang dapat bekerja lebih baik dalam menentukan kebutuhan pelanggan
       3. Pelanggan berperan aktif dalam pengembangan sistem
       4. Lebih menghemat waktu dalam pengembangan sistem
       5. Penerapan menjadi lebih mudah karena pemakai mengetahui apa yang diharapkannya.


Kelemahan prototyping adalah :
       1. Pelanggan kadang tidak melihat atau menyadari bahwa perangkat lunak yang ada
           belum mencantumkan kualitas perangkat lunak secara keseluruhan dan juga belum
           memikirkan kemampuan pemeliharaan untuk jangja waktu lama.


       2. penegmbang biasanya ingin cepat menyelesaikan proyek. Sehingga menggunakan
           algoritma dan bahasa pemrograman yang sederhana untuk membuat prototyping
           lebih cepat selesai tanpa memikirkan lebih lanjut bahwa program tersebut hanya
           merupakan cetak biru sistem .


       3. Hubungan pelanggan dengan komputer yang disediakan mungkin tidak
           mencerminkan teknik perancangan yang baik


Prototyping bekerja dengan baik pada penerapan-penerapan yang berciri sebagai berikut :


       1. Resiko tinggi Yaitu untuk maslaha-masalah yang tidak terstruktur dengan baik, ada
           perubahan yang besar dari waktu ke waktu, dan adanya persyaratan data yang tidak
              menentu.


       2. Interaksi pemakai penting . Sistem harus menyediakan dialog on-line antara
           pelanggan dan komputer.


       3. Perlunya penyelesaian yang cepat


       4. Perilaku pemakai yang sulit ditebak


       5. Sitem yang inovatif. Sistem tersebut membutuhkan cara penyelesaian masalah dan
           penggunaan perangkat keras yang mutakhir


       6. Perkiraan tahap penggunaan sistem yang pendek

Metode Waterfall

Waterfall

         Waterfall adalah suatu metodologi pengembangan perangkat lunak yang mengusulkan pendekatan kepada perangkat lunak sistematik dan sekuensial yang mulai pada tingkat kemajuan sistem pada seluruh analisis, design, kode, pengujian dan pemeliharaan.

Langkah-langkah yang harus dilakukan pada metodologi Waterfall adalah sebagai berikut:

1. Analisis kebutuhan perangkat lunak

Proses pengumpulan kebutuhan diintensifkan dan difokuskan, khususnya pada perangkat lunak. Untuk memahami sifat program yang dibangun, rekayasa perangkat lunak (analisis) harus memahami domain informasi, tingkah laku, unjuk kerja dan antar muka (interface) yang diperlukan. Kebutuhan baik untuk sistem maupun perangkat lunak di dokumentasikan dan dilihat dengan pelanggan.

2. Desain

Desain perangkat lunak sebenarnya adalah proses multi langka yang berfokus pada empat atribut sebuah program yang berbeda; struktur data, asitektur perangkat lunak, representasi interface dan detail (algoritma) prosedural.  Proses desain menerjemahkan syarat/kebutuhan kedalam sebuah representasi perangkat lunak yang dapat di perkirakan demi kualitas sebelum dimulai pemunculan kode. Sebagaimana persyaratan, desain didokumentasikan dan menjadi bagian  dari konfigurasi perangkat lunak.

3. Generasi Kode

Desain harus diterjemahkan dalam bentuk mesin yang bisa di baca. Langkah pembuatan kode melakukan tugas ini. Jika desain dilakukan dengan cara yang lengkap, pembuatan kode dapat diselesaikan secara mekanis.

4. Pengujian

        Proses pengujian dilakukan pada logika internal untuk memastikan semua pernyataan sudah diuji. Pengujian eksternal fungsional untuk menemukan kesalahan-kesalahan dan memastikan bahwa input akan memberikan hasil yang aktual sesuai yang dibutuhkan


      5.   Pemeliharaan

       Perangkat lunak yang sudah disampaikan kepada pelanggan pasti akan mengalami perubahan. Perubahan tersebut bisa karena mengalami kesalahan karena perangkat lunak harus menyesuaikan dengan lingkungan (periperal atau sistem operasi baru) baru, atau karena pelanggan membutuhkan perkembangan fungsional atau unjuk kerja.

Keunggulan dan Kelemahan Model Sekuensial Linier

a. Keunggulan
       1. Mudah aplikasikan
       2. Memberikan template tentang metode analisis, desain, pengkodean, pengujian, dan
           pemeliharaan

b. Kelemahan
       1. Jarang sekali proyek riil mengikuti aliran sekuensial yang dianjurkan model karena
           model ini bisa melakukan itersi tidak langsung . Hal ini berakibat ada perubahan
           yang diragukan pada saat proyek berjalan.
       2. Pelanggan sulit untuk menyatakan kebutuhan secara eksplisit sehingga sulit untuk
           megakomodasi ketidakpastian pada saat awal proyek.
       3. Pelanggan harus bersikap sabar karena harus menunggu sampai akhir proyrk dilalui.
           Sebuah kesalahan jika tidak diketahui dari awal akan menjadi masalah besar kare
           harus mengulang dari awal.
       4. Pengembang sering malakukan penundaan yang tidak perlu karena anggota tim
           proyek harus menunggu tim lain untuk melengkapi tugas karena memiliki
           ketergantungan hal ini menyebabkan penggunaan waktu tidak efesien


       

RPL

REKAYASA PERANGKAT LUNAK (RPL)

Definisi Rekayasa Perangkat Lunak Menurut Fritz Bauer :

       "Penerapan dan pemanfaatan prinsip-prinsip rekayasa untuk menghasilkan perngkat lunak yang ekonomis

       yang handal dan bekerja secara efisisen pada mesin-mesin yang nyata"

Karakteristik Perangkat Lunak

       - Dikembangkan atau direkayasa, tidak dibuat dalam pengertian pada umumnya.

       - Tidak 'lapuk' atau mengalami penyusutan secara fisis.

       - Pada umumnya dibuat secara khusus, tidak disusun dari komponen-komponen yang telah ada.

Problem Perangkat Lunak

       - Perangkat lunak tidak berfungsi secara baik (kualitas yang kurang).

       - Ketidaktepatan penjadwalan proses dan biaya produksi.

       - Produktivitas yang belum dapat memenuhi tuntutan kebutuhan pemakai.

       - Pemeliharaan yang sukar.

       - Perkembangan teknologi perangkat keras di luar kemampuan programmer untuk membuat perangkat lunak yang dapat

         memanfaatkan potensi perangkat keras secara maksimal.

Elemen-elemen Kunci dalam RPL
       - Metode : 'how to' yang bersifat teknis

         Meliputi bidang-bidang perencanaan proyek, estimasi, analisis persyaratan, perancangan, coding, pengujian, dan pemeliharaan.

       - Tool : memberikan dukungan automasi bagi metode

       - Prosedur : mengintegrasikan metode dan tool