-
Rekayasa Perangkat Lunak
1
BAB I
PENGENALAN REKAYASA PERANGKAT LUNAK
1. Perangkat Lunak
1. Pengertian Perangkat Lunak
Gambaran perangkat lunak pada sebuah buku teks mungkin mengambil
bentuk
berikut : (1) perintah (program komputer) yang bila dieksekusi
memberikan fungsi dan
unjuk kerja seperti yang diinginkan. (2) Struktur data yang
memungkinkan program
memanipulasi informasi secara proporsional, dan (3) dokumen yang
menggambarkan
operasi kegunaan program.
2. Karakteristik Perangkat Lunak
Perangkat lunak lebih merupakan elemen logika dan bukan
merupakan elemen
fisik. Dengan demikian, perangkat lunak memiliki ciri yang
berbeda dari perangkat
keras. Ciri-ciri yang membedakan tersebut antara lain :
1. Perangkat lunak dibangun dan dikembangkan, tidak dibuat dalam
bentuk yang
klasik.
Meskipun terdapat kesamaan antara pembuatan perangkat keras dan
pengembangan
perangkat lunak, yaitu kualitas yang tinggi bisa dicapai melalui
perancangan yang
baik, tetapi di dalam fase pembuatan perangkat keras selalu saja
ditemukan masalah
kualitas yang tidak mudah disesuaikan dengan perangkat
lunak.
2. Perangkat lunak tidak pernah usang
Gambar 1.1. Kurva Kegagalan Perangkat Keras
Gambar 1.1 menggambarkan laju kegagalan sebagai fungsi waktu
untuk
perangkat keras, disebut ‘kurva bathtub”, menunjukkan bahwa
perangkat keras
mengalami laju kegagalan yang sangat tinggi pada awal hidupnya,
yang disebabkan
kematian
segera usang
Waktu
Tingkat
Kegagalan
-
Rekayasa Perangkat Lunak
2
oleh perancangan atau cacat pembuatannya. Setelah diperbaiki
maka laju kegagalan
menurun, kemudian naik lagi pada saat komponen perangkat keras
terkena
penumpukkan debu, getaran, suhu tinggi, serta pengaruh
lingkungan yang lain.
Secara singkat dapat dikatakan bahwa perangkat keras sudah mulai
usang.
Sedangkan perangkat lunak tidak rentan terhadap pengaruh
lingkungan yang
merusak dan menyebakan perangkat keras menjadi usang.
Gambar 1.2 secara teoritis menggambarkan tingkat kegagalan
perangkat lunak.
Kesalahan-kesalahan yang tidak ditemukan akan menyebabkan
tingkat kegagalan
tinggi pada awal hidup program, tetapi itu dapat diperbaiki
sehingga kurvanya
menjadi datar. Secara singkat perangkat lunak tidak usang,
meskipun pada
kenyataannya semakin lama makin memburuk.
Gambar 1.2. Kurva Kegagalan Perangkat Lunak
Selama masa hidupnya, perangkat lunak mengalami perubahan
(pemeliharaan).
Sewaktu perubahan dibuat, kesalahan lain akan muncul yang
menyebabkan kurva
kegagalan naik secara cepat. Lihat Gamabr 1.3. Setelah semua
kesalahan diperbaiki
maka kurva akan menjadi normal kembali. Kemudian secara perlahan
tingkat laju
kesalahan minimum mulai naik – perangkat lunak mulai memburuk
sehubungan
perubahan yang dilakukan.
Pada tingkat yang sama
sampai usang
Waktu
Tingkat
Kegagalan
-
Rekayasa Perangkat Lunak
3
Gambar 1.3. Kurva Kegagalan Aktual Perangkat Lunak
Aspek lain dari keusangan yang membedakan antara perangkat keras
dan lunak
adalah bila perangkat keras telah usang maka bisa diganti dengan
suku cadangnya,
tetapi tidak demikian dengan perangkat lunak.
3. Sebagian besar perangkat lunak dibuat secara custom-built,
serta tidak dapat dirakit
dari komponen yang sudah ada.
Perhatikan bagaimana perangkat keras komputer dirancang dan
dibuat. Pengembang
desain menggambar skema sederhana dari rangkaina digital,
melakukan serangkaian
analisis dasar untuk memastikan bahwa fungsi yang tepat dapat
dicapai serta
kemudian menyesuaikan ke katalog komponen digital. Setiap IC
(chip) mempunyai
nomor tersendiri, sebuah fungsi yang telah tervalidasi,
interface yang didefinisikan
dengan baik, serta rangkaian standar tuntunan integrasi. Setelah
masing-masing
komponen diseleksi, perangkat keras bisa dipesan secara
terpisah. Tidak demikian
dengan pengembangan perangkat lunak, katalog komponen perangkat
lunak tidak
ada. Memang memungkinkan memesan perangkat lunak secara
terpisah, tetapi tetap
merupakan satu kesatuan yang lengkap, bukan sebagai komponen
yang dapat
dipasang ke dalam program-program yang baru.
-
Rekayasa Perangkat Lunak
4
3. Evolusi Perangkat Lunak.
Pada awal tahun 1990-an Toffler menggambarkan adanya pergeseran
kekuatan
dimana struktur kekuatan lama (pemerintah, pendidikan, industri,
dan militer)
mengalami disintegrasi ketika komputer membawa ke arah
demikratisasi pengetahuan.
Sedangkan pada tahun 1992 Yourdon mengkawatirkan
perusahaan-perusahaan Amerika
akan kehilangan sisi kompetitif mereka di dalam bisnis yang
berhubungan dengan
perangkat lunak dan meramalkan penurunan serta jatuhnya para
pemrogram Amerika.
Tahun 1993 Hammer dan Champy berpendapat bahwa teknologi
informasi akan
memainkan peranan sentral dalam pengembangan kerjasama. Pada
pertengahan tahun
1990 daya tembus komputer dan perangkat lunak menimbulkan banyak
pendapat bahwa
komputer menekankan sisi legitimasi tetapi mengabaikan
keuntungan besar yang
diperoleh.
Perkembangan perangkat lunak bisa digambarkan pada Gambar 1.4.
Pada masa
awal era komputer, perangkat lunak dilihat hanya sebagai suatu
permenungan.
Pemrogram komputer menjadi sebuah seni “seat-of-pants” dimana di
situ terdapat
beberapa metode yang sistematis. Perkembangan perangkat lunak
sebenarnya tidak bisa
diatur sampai terjadi jadwal yang bergeser, atau biaya yang
mulai melonjak. Para
pemrogram kemudian berusaha untuk membuat semuanya benar
kembali, dan dengan
cara yang heroik akhirnya mereka berhasil. Pada masa itu
perangkat lunak dirancang
secara khusus untuk aplikasi tertentu saja dan hanya memiliki
areal distribusi yang
terbatas. Produk perangkat lunak yang dijual kepada pelangan
atau masyarakat masih
langka. Kebanyak dikembangkan dan digunakan oleh orang atau
organisasi yang sama,
dibuat untuk dipakai sendiri.
Era kedua evolusi sistem komputer antar pertengahan tahun 1960
dan 1970-an.
Sistem multiprogram dan multiuser memperkenalkan konsep baru
interaksi manusia dan
mesin. Teknik interaktif membuka sebuah dunia aplikasi yang baru
serta tingkat
kecanggihan perangkat lunak dan perangkat keras yang baru pula.
Sistem real-time
mampu melakukan pengontrolan dalam menghasilkan output tidak
lagi dalam skala
menit, melainkan detik. Kemajuan dalam penyimpanan on-line
membawa ke generasi
pertama sistem mamajemen database. Pada era kedua ini juga
ditandai dengan
kehadiran software-house. Produk perangkat lunak didistribusikan
ke pasar yang lebih
luas dan multidisiplin. Program mainframe dan minikomputer
didistribusikan kepada
-
Rekayasa Perangkat Lunak
5
masyarakat luas. Pengusaha, pemerintah, industri, serta
akademisi masing-masing
mengembang-kan paket perangkat lunak paling mewah dengan
mengeruk banyak uang.
Tahun-tahun
awal
Era kedua Era Ketiga Era keempat
- Orientasi batch - Multi user - Sistem terdistribusi - Sistem
desk-top
bertenaga kuat
- Distribusi
terbatas - Realtime
- embedded
intelegence
- Teknologi berorientasi
objek
- Perangkat
lunak
kustomasi
- Database - Perangkat keras
biaya rendah - Sistem pakar
- Perangkat
lunak produk - Jaringan saraf tiruan
- Komputasi paralel
- Komputer jaringan
Gambar 1.4. Evolusi Perangkat Lunak
Era ketiga evolusi sistem komputer dimulai pertengahan tahun
1970-an dan berlangsung
lebih dari satu dekade penuh. Sistem terdistribusi dan
multikomputer menambah
kompleksitas sistem berbasis komputer. Jaringan area global dan
lokal, jaringan
komunikasi digital dengan bandwidh yang tinggi serta pertambahan
permintaan untuk
akses “sesaat” sangat mendongkrak perkembangan perangkat lunak.
Era ketiga ini juga
ditandai dengan kehadiran dan penyebaran pemakaian
mikroprosesor, sehingga produk-
produk pintar, seperti automobil, microwave, robot sampai
peralatan kedokteran bisa
dihasilkan. Yang paling penting pada era ini adalah munculnya
komputer personal (PC
= Personal Computer).
1950 1960 1970 1980 1990 2000
-
Rekayasa Perangkat Lunak
6
Evolusi sistem komputer era keempat menjauhkan kita dari
komputer individual
dan program komputer untuk menuju pengaruh kolektif dari
komputer dan perangkat
lunak. Mesin desktop yang kuat yang dikontrol oleh sistem
operasi yang canggih,
jaringan lokal dan global, serta didukung dengan aplikasi
perangkat lunak yang maju,
menjadi sebuah aturan. Arsitektur penghitungan berubah dari
lingkungan mainframe
yang terpusat ke lingkungan klien/server yang terdesentralisasi.
Dan yang paling
penting pada era ini adalah internet sudah dapat dilihat sebagai
perangkat lunak yang
dapat diakses oleh para pemakai individual.
Tetapi selama era evolusi sistem berbasis komputer, serangkaian
masalah yang
berhubungan ddengan perangkat lunak masih muncul dengan
intensitas yang terus
bertambah, misalnya :
1. Kemajuan perangkat keras terus berlajut, melampaui
perkembangan perangkat
lunak yang sesuai dengan perangkat keras yang ada.
2. Kemampuan pengembangan perangakt lunak tidak cukup sepat
untuk memenuhi
kebutuhan bisnis dan pasar.
3. Pemakaian komputer yang semakin luas membuat masyarakat
semakin
tergantung pada perangkat lunak yang reliabel.
4. Sistem desain dan sumberdaya untuk mengembangkan perangkat
lunak kurang
memadai, sehingga masih sulit untuk dibagun perangkat lunak
dengan
reliabilitas dan kualitas yang tinggi.
4. Aplikasi Perangkat Lunak
Perangkat lunak dapat diaplikasikan ke berbagai situasi dimana
serangakaian
langkah prosedural (seperti algoritma) telah didefinisikan.
Kandungan (content) dan
determinasi informasi merupakan faktor penting dalam menentukan
sifat aplikasi
perangkat lunak. Content mengarah pada arti dan bentuk informasi
yang masuk dan
keluar. Misalnya, banyak aplikasi bisnis memakai data input
dengan struktur data lebih
tinggi (misal database) dan mengahasilkan laporan yang sudah
terformat. Perangkat
lunak yang mengontrol mesin otomatis menerima bentuk data
diskrit dengan struktur
yang terbatas dan menghasulkan perintah mesin individual dalam
ekskusi yang cepat.
Sedangkan determinasi informasi merujuk pada predikbilitas
urutan dan timing
informasi.
-
Rekayasa Perangkat Lunak
7
Berikut beberapa jenis aplikasi perangkat lunak :
a. Perangkat lunak sistem. Sekumpulan program untuk melayani
program–program
lain, misalnya sistem operasi, kompiler, editor, utilitas
pengatur file, driver, prosesor
telekomunikasi.
b. Perangkat lunak real-time. Program-program untuk
mengontrol/menganalisis/
memonitor kejadian dunia nyata pada saat terjadinya. Misalnya
program untuk
mengontrol mesin industri.
c. Perangkat lunak bisnis. Program untuk pemrosesan informasi di
dunia bisnis, mulai
dari payroll, account payable, inventory, post system, sampai
perangkat lunak
sistem informasi manajemen yang bisa mengakses satu atau lebih
database.
d. Perangkat lunak teknik dan ilmu pengetahuan. Jangkauan
aplikasinya meliputi,
asmronomi, vulkanologi, kedokteran, analisis otomotif, biologi,
mesin-mesin pabrik,
sampai pada perangkat bantu dalam perancangan (computer aided
design) untuk
konstuksi bangunan, komponen elektronik, rancangan mesin,
simulasi sitem, dan
lain-lain.
e. Embeded Software. Program yang disertakan dalam suatu
perangkat dan berfungsi
untuk mengontrol hasil serta sistem perangkat tersebut. Contoh :
key pad control
untuk microwave, fungsi digital pada automobil (pengontrol bahan
bakar,
penampilan dash board, sistem rem, dll).
f. Perangkat lunak komputer personal. Program–program yang bisa
dijalankan pada
komputer personal. Contoh : pengolah kata, multimedia, hiburan,
manajemen
database, aplikasi keuangan bisnis, dll.
g. Perangkat lunak kecerdasan buatan dan jaringan syaraf tiruan.
Sistem pakar atau
disebut juga sistem berbasis pengetahuan. Program yang digunakan
untuk
menggerakkan/mengontrol robot, permainan game, pengolah gambar
dan pola
(image dan voice).
-
Rekayasa Perangkat Lunak
8
2. Rekayasa Perangkat Lunak
1. Pengertian Rekayasa Perangkat Lunak
Pada tahun 1969 Fritz Bauer memberikan definisi rekayasa
perangkat lunak
adalah sebagai berikut :
“The establishment and use of sound engineering principles in
order to
obtain economically software that is reliable and work
efficiently on
real machines.”
Hampir setiap pembaca tergoda untuk menambah sendiri definisi
tersebut,
karena definisi tersebut hanya menyinggung sedikit saja tentang
aspek teknis dan
kualitas perangkat lunak, dan tidak secara langsung menyinggung
kebutuhan dan
kepuasan pelanggan, pengabaikan pencamtuman pentingnya
pengukuran dan matriks,
tidak menyinggung pentingnya sebuah proses. Apakah sound
enginnering aplication
yang dapat diaplikasikan kepada pengembangan komputer? Bagaimana
kita secara
ekonomis membangun perangkat lunak sehingga menjadi dapat
diandalkan dan
reliable? Apakah yang dibutuhkan untuk menciptakan program
komputer yang bekerja
secara efisien pada lebih dari satu mesin riril yang berbeda?
Pertanyaan-pertanyaan ini
masih terus menjadi tantangan bagi pengembangan perangkat
lunak.
Pada tahun 1985 Richard Fairly mendefinisikan rekayasa perangkat
lunak
sebagai berikut :
“The technological and managerial dicipline concernment with
systematic production and maintenance of software products that
are
developed and modified on time and within cost estimates.”
Definisi ini sudah menyinggung aspek teknis pengembangan
perangkat lunak,
pengelolaan tim yang terlibat dalam pengembangan tersebut,
pemeliharaan perangkat
lunak yang telah dikembangkan, serta waktu serta biaya
pengem-bangan.
Kemudian pada tahun 1993, IEEE mengembangkan definisi yang
lebih
komprehensif yaitu sebagai berikut :
Rekayasa perangkat lunak adalah : (1) Aplikasi dari sebuah
pendekatan
kuantifiabel, disiplin, dan sistematis terhadap pengembangan,
operasi,
dan pemeliharaan perangkat lunak; yaitu aplikasi dan
rekayasa
perangkat lunak; (2) Studi tentang pendekatan-pendekatan tentang
(1).
-
Rekayasa Perangkat Lunak
9
2. Lingkup Rekayasa Perangkat Lunak
Lingkup rekayasa perangkat lunak bisa digambarkan seperti Gambar
1.5.
Rekayasa perangkat lunak merupakan suatu kegiatan untuk
menghasilkan suatu produk,
sehingga harus berada pada satu komitmen dasar menuju kualitas.
Untuk itu fokus
kualitas menjadi batu landasanya. Lingkup kedua adalah proses.
Proses-proses rekayasa
perangkat lunak adalah perekat yang menjaga bentangan teknologi
secara bersama-sama
dan memungkinkan perkembangan perangkat lunak yang tepat waktu
dan rasional.
Proses-proses tersebut membatasi kerangka kerja untuk
serangkaian area proses kunci
yang harus dibangun demi keefektifan penyampaian teknologi
pengembangan perangkat
lunak. Area proses kunci ini membentuk dasar bagi kontrol
manajemen proyek
pengembangan perangkat lunak serta membangun kontek dimana
metode teknis
diaplikasikan sehingga sebuah produk yang berkualitas bisa
dihasilkan.
Gambar 1.5. Lingkup Rekayasa Perangkat Lunak.
Lingkup berikutnya adalah metodologi, yaitu sekumpulan metode
untuk
melaksanakan setiap tahap pengembangan perangkat lunak, yang
meliputi : perencanaan
dan estimasi proyek, analisa kebutuhan, prosedur algoritma dan
arsitektur program,
menulis program (coding), pengujian (testing), dan pemeli-haraan
(maintenance).
Terakhir adalah perangkat bantu (tools). Perangkat bantu yang
dimaksus adalah suatu
perangkat, baik lunak atau keras, otomatis maupun semi-otomatis
yang bisa digunakan
untuk proses pengembangan perangkat lunak. Tools untuk rekayasa
perangkat lunak
disebut computer-aided sofware engineering (CASE). CASE ini
terus dikembangkan
untuk menciptakan lingkungan rekayasa perangkat lunak sehingga
analog dengan
CAD/CAE (computer-aided design/engineering) pada pengembangan
perangkat keras.
Fokus kualitas
proses
metodologi
perangkat bantu
-
Rekayasa Perangkat Lunak
10
3. Paradigma Rekayasa Perangkat Lunak
Untuk menyelesaikan masalah aktual didalam sebuah seting
industri, rekayasa
perangkat lunak atau tim perekaysa harus menggabungkan strategi
pengembangan yang
mencakup semua lingkup rekayasa perangkat lunak seperti yang
digambarkan pada
Gambar 1.5 tersebut . Strategi ini sering disebut paradigma atau
model proses rekayasa
perangkat lunak.
Perkembangan perangkat lunak bisa dianggap sebagai lingkaran
pemecahan
masalah dimana terdapat empat keadaan berbeda, yaitu status quo,
definisi masalah,
perkembangan teknis pemecahan masalah, dan integrasi pemecahan
menyampaikan
hasil (dokumen, program, data, fungsi bisnis baru, produk baru)
kepada yang
membutuhkan hasil/produk tersebut. Lihat Gambar 1.6.
Lingkaran pemecahan masalah tersebut digunakan pada tingkat
makro ketika
bagian dalam aplikasi dipakai; pada tingkat tengah ketika
komponen program
direkayasa; dan pada tingkat mikro ketika baris-baris kode
ditulis. Masing-masing
keadaan di dalam pemecahan masalah tersebut berisi lingkaran
yang identik. Lihat
Gambar 1.7. Tanpa memperdulikan model proses yang dipilih untuk
suatu proyek
rekayasa perangkat lunak, semua keadaan tersebut -- status quo,
definisi masalah,
perkembangan teknis pemecahan masalah, dan integrasi pemecahan –
secara simultan
hidup berdampingan pada beberapa tingkatan / tahapan detail.
Dalam subbab ini akan dibahas beberapa model proses yang berbeda
pada
rekaya perangkat lunak.
Gambar 1.6. Fase lingkaran pemecahan masalah
Definisi masalah
Penyatuan Solusi
Pengembangan Teknis Status
Quo
-
Rekayasa Perangkat Lunak
11
Gambar 1.7. Fase-fase di dalam lingkaran pemecahan masalah
a. Siklus Hidup Klasik
Paradigma siklus hidup klasik untuk rekayasa perangkat lunak
diilustrasikan
seperti pada Gambar 1.8. Disebut juga sebagai “model air
terjun”.
Beberapa kelebihan model ini adalah :
1) Titik awal dan titik akhir yang eksplisit
2) Setiap tahapan didefinisikan dengan jelas
3) Setiap akhir suatu tahap, disesuikan kembali dengan tahap
sebelumnya, sehingga
kesalahan yang mungkin terjadi bisa ditemukan dan diselesaikan
lebih dini.
Definisi masalah
Penyatuan Solusi
Pengembangan Teknis
Status Quo
Definisi masalah
Penyatuan Solusi
Pengembangan Teknis
Status Quo
Definisi masalah
Penyatuan Solusi
Pengembangan Teknis
Status Quo Status
Quo
-
Rekayasa Perangkat Lunak
12
4) Incremental release, lingkup kerja untuk tahapan-tahapan
berikutnya menjadi lebih
kecil, dan tugas yang lebih mudah. Jika tahap awal dilakukan
dengan benar maka
akan mempermudah tahap berikutnya.
Gambar 1.8. Paradigma Siklus Hidup Klasik : “Model Air
Terjun”
Aktivitas setiap tahapannya adalah :
1) System Engineering : Pengumpulan kebutuhan seluruh elemen
sistem
2) Sofware Requirements Analysis : Pengumpulan kebutuhan dengan
berfokus pada
perangkat lunak, meliputi : domain informasi, fungsi, unjuk
kerja, antar muka
3) Design, meliputi : Perancang struktur data, arsitektur
perangkat lunak, rincian
prosedural, karakteristik antar muka
4) Coding : penerjemah perancang ke bentuk yang dapat dimengerti
oleh mesin
5) Testing, mencakup kegiatan : penguji lojikal, penguji
fungsional, menemukan
kesalahan dan memastikan suatu masukan diproses menjadi keluaran
yang sesuai
dengan yang diinginkan
6) Maintenance, bagian terujung dari siklus pengembangan dan
dilakukan setelah
perangkat lunak dipergunakan. Kegiatan adalah corrective
maintenance, yaitu
mengkoreksi kesalahan pada perangkat lunak, yang baru terdeteksi
pada saat
perangkat lunak dipergunakan
Software
Enginering
Analysis
Design
Coding
Testing
Maintenance
-
Rekayasa Perangkat Lunak
13
Model air terjun adalah paradigma rekayasa perangkat lunak yang
paling luas
dipakai dan paling tua. Tetapi kritik terhadap paradigma
tersebut menyebabkan banyak
pihak yang mempertanyakan kehandalannya. Masalah-masalah yang
timbul ketika
model tersebut diterapkan adalah :
1. Meskipun dalam prosesnya model ini bisa mengakomodasi
iterasi, tetapi tidak
dilakukan secara langsung, akibatnya perubahan-perubahan dapat
menyebabkan
keraguan pada saat tim proyek berjalan.
2. Kadang-kadang pelanggan sulit untuk menyatakan semua
kebutuhannya secara
eksplisit, sehingga sulit untuk mengakomodasi ketidakpastian
tersebut.
3. Pelanggan harus bersikap sabar, karena masa pakai dari
program tidak akan
diperoleh sampai akhir waktu proyek berakhir. Akibatnya bisa
saja terdapat
kesalahan yang tidak tedeteksi sampai program tersebut tiba
masanya untuk dikaji
ulang.
4. Pengembang sering melakukan penundaan yang tidak perlu,
karena seringnya
beberapa anggota tim proyek harus menunggu anggota lain untuk
melengkapi tugas
yang saling ketergantungan.
b. Model Prototype
Sering kali seorang pelanggan mendefinisikan serangkaian umum
bagi
perangkat lunak yang dibutuhkan, tetapi tidak mengidentifikasi
kebutuhan output,
pemrosesan, maupun input secara detail. Pada kasus lain,
pengembang tidak memiliki
kepastian terhadap efisiensi algoritma, kemampuan penyesuaian
dari sebuah sistem
operasi, atau bentuk-bentuk yang harus dilakukan oleh interaksi
manusia dan mesin.
Dalam hal ini, paradigma prototipe menawarkan pendekatan yang
terbak.
Paradigma ini dimulai dengan mengumpulkan kebutuhan. Pengembang
dan
pelanggan bertemu untuk mendefinisikan obyektif keseluruhan dari
perangkat lunak.
Kemudian dilakukan perancangan kilat yang berfokus pada
penyajian dari aspek-aspek
perangakt lunak yang akan nampak oleh pelanggan/pemakai (misal
format input dan
outputnya). Perancangan kilat tersebut membawa kepada konstruksi
prototipe. Prototipe
ini dievaluasi oleh pelanggan/pemakai dan dipakai untuk
menyaring kebutuhan
pengembangan perangkat lunak yang dibutuhkan. Iterasi terjadi
pada saat prototipe
-
Rekayasa Perangkat Lunak
14
disetel untuk memenuhi kebutuhan pelanggan, dan pada saat yang
sama memungkinkan
pengembang untuk secara lebih baik memahami apa yang harus
dilakukan.
Prototipe bisa berfungsi sebagai “sistem awal”. Tetapi pada
beberapa proyek
yang dibangun dengan prototipe, saat penggunaan pertama sistem
awal yang baru
dibangun tersebut, mungkin akan terasa terlalu pelan, terlalu
besar, janggal dalam
pemakaian, atau bahkan tiga hal tersebut semua terjadi. Jika
terjadi demikian maka tidak
ada pilihan lain kecuali memulai lagi untuk membangun versi yang
baru dimana
masalah yang muncul bisa diselesaikan.
c. Model RAD (Rapid Aplication Development).
RAD adalah merupakan model proses pengembangan perangkat lunak
adaptasi
kecepatan tinggi dari model sekuensial linier yang menekankan
siklus perkembangan
yang sangat pendek. Perjalanan pengembangannya sangat cepat
dengan menggunakan
pendekatan konstruksi berbasis komponen, yang memungkinkan tim
pengembang bisa
menciptakan sistem fungsional secara utuh dalam waktu 60 s.d. 90
hari. Pada umumnya
digunakan pada aplikasi sistem konstruksi.
Pendekatan RAD melingkupi fase-fase sebagai berikut :
1) Businnes modelling. Pemodelan dari aliran informasi diantara
fungsi-fungsi bisnis.
2) Data modelling. Mengidentifikasi serangkaian objek data yang
dibutuhkan dan
karakteristik masing-masing objek tersebut, serta mendefinisikan
hubungan antara
objek-objek tersebut.
3) Proses modelling. Mentransformasikan hasil data modelling
untuk mencapai aliran
informasi yang perlu bagi implementasi fungsi-fungsi prosesnya.
Gambaran proses
dibuat untuk menambah, memodifikasi, menghapus, atau mendapatkan
kembali
sebuah objek data.
4) Aplication generation. RAD mengasumsikan pemakaian teknik
generasi keempat
(4GL), lebih banyak memakai komponen program yang sudah ada,
juga
menciptakan komponen yang bisa dipakai lagi.
5) Testing and turnover. Karena proses RAD menekankan pada
pemakaian kembali,
maka setiap komponen baru harus diuji untuk mengurangi
keseluruhan waktu
pengujian
-
Rekayasa Perangkat Lunak
15
Kelemahan model RAD :
1) Bagi proyek yang besar tetapi berskala, RAD memerlukan sumber
daya manusi
yang memadai untuk menciptakan jumlah tim RAD yang baik.
2) RAD menuntut pengembang dan pelanggan memiliki komitmen
tinggi di dalam
aktivitas pengembangan.
Gambar 1.9. Model RAD
Disamping tiga model di atas, masih banyak lagi model proses
rekayasa
perangkat lunak yang lain, yaitu :
1) Model Proses Rekayasa Perangkat Lunak Evolusioner, antara
lain :
a) Model Pertambahan
b) Model Spiral
c) Model Rakitan Komponen
d) Model Perkembangan Konkuren
Pemodelan
bisnis
Pemodelan
data
Pemodelan
Proses
Pembentukan
aplikasi
Pengujian
& turnover
Pemodelan
bisnis
Pemodelan
data
Pemodelan
Proses
Pembentukan
aplikasi
Pengujian
&
turnover
Pemodelan
bisnis
Pemodelan
data
Pemodelan
Proses
Pembentukan
aplikasi
Pengujian
& turnover
Tim #1
Tim #2
Tim #3
-
Rekayasa Perangkat Lunak
16
2) Model Formal
3) Teknik Generasi Keempat (4GL)
Model-model itu bisa anda baca di buku “Software Engineering”
yang ditulis oleh
Rogers. Pressman, PhD.
3. Rekayasa Sistem Komputer
Dengan melihat definisi dari Webster’s, kita mendefinisikan
sistem berbasis
komputer sebagai:
“serangkaian atau tatanan elemen-elemen yang diatur untuk
mencapai tujuan yang
ditentukan sebelumnya melalui pemrosesan informasi”
Tujuannya adalah untuk mendukung berbagai fungsi bisnis atau
untuk mengembangkan
suatu produk yang dapat dijual untuk menghasilkan keuntungan
bisnis. Untuk mencapai
tujuan tersebut, sistem berbasis komputer menggunakan berbagai
elemen sistem:
a) Perangkat lunak, program komputer, struktur data, dan dokumen
yang
berhubungan yang berfungsi untuk mempengaruhi metode logis,
prosedur, dan
kontrolyang dibutuhkan.
b) Perangkat keras, perangkat elektronik yang memberikan
kemampuan
penghitungan, dan perangkat elektromekanik (misalnya: sensor,
rotor,
pompa)yang memberikan fungsi dunia eksternal.
c) Manusia, pemakai dan operator perangkat lunak dan perangkat
keras.
d) Database, kumpulan informasi yang besar dan terorganisasi
yang diakses
melalui perangkat lunak.
e) Dokumentasi, manual, formulir, dan informasi deskriptif
lainnya yang
menggambarkan penggunaan dan pengoprasian sistem.
f) Prosedur, langkah-langkah yang menentukan penggunaan khusus
dari masing
elemen sistem atau konteks prosedural dimana sistem berada.
Satu karakteristik sistem berbasis komputer yang rumit adalah
bahwa elemen yang
berisi satu sistem juga dapat mewakili satu elemen makro dari
suatu sistem yang
sangat besar. Elemen makro adalah suatu sistem berbasis komputer
yang merupakan
bagian dari sistem berbasis komputer yang lebih besar lagi.
Peran rekayasa sistem
adalah membatasi elemen-elemenuntuk sistem berbasis komputer
tertentu dalam
konteks keseluruhan hirarki sistem (elemen makro). Berikut
adalah tugas-tugas yang
merupakan rekayasa sistem komputer:
-
Rekayasa Perangkat Lunak
17
Sistem Otomasi Pabrik
Sistem Pemanufakturan Sistem Inventori Sistem Informasi
Sistem Aliran Material Sel pemenufakturan
RobotMesin NC Perangkat Entry Data
Gambar 1.10. Sistem dari banyak sistem
-
Rekayasa Perangkat Lunak
18
BAB II
DASAR ANALISIS KEBUTUHAN
2.1. Lingkup Analisis
a) Pengenalan Permasalahan
b) Evalusi dan Sintesis
c) Pemodelan
d) Spesifikasi
e) Peninjauan Ulang
Gambar 2.1 Hubungan Antara Analisis dan Perancangan
Dalam menemukan area permasalahan, perlu adanya komunikasi yang
intensif
dengan user. Hal yang perlu diperhatikan dalam berkomunikasi
adalah menghindari
salah interpretasi.
Pertanyaan pertama memfokuskan pada pengertian dasar
permasalahan :
1. Menemukan yang membutuhkan software tersebut :
a. Siapa yang membutuhkan sistem (serta personal di
belakangnya?)
b. Siapa yang akan menggunakan solusi
c. Apa yang akan menjadi keuntungan ekonomis dari solusi yang
baik
d. Adakah sumber lain dari solusi yang dibutuhkan
2. Bentuk solusi yang diinginkan
a. Bagaimana user mengkarakteristikkan suatu output sistem yang
baik yang akan dihasilkan oleh solusi yang benar
b. Masalah-masalah apa yang akan dicarikan solusinya? c.
Lingkungan solusi yang akan digunakan d. Adakah isukah isu atau
kendala khusus yang berdampak kepada solusi
3. Efektifitas
a. Mendapatkan person yang benar/berhak atas jawaban pertanyaan,
b. Apakah pertanyaan yang diajukan relevan dengan permasalahan c.
Adakah personal lain yang dapat menambah informasi
Analisis
Peran- cangan
Apa ? Bagaimana ?
-
Rekayasa Perangkat Lunak
19
d. Adakah hal lain yang perlu ditambahkan?
Jenis Kebutuhan: 1) Kebutuhan Fungsional
Pendefinisian layanan yang harus disediakan, bagaimana reaksi
sistem terhadap
input dan apa yang harus dilakukan sistem pada situasi khusus
(Kebutuhan sistem
dilihat dari kacamata pengguna)
2) Kebutuhan Non-Fungsional Kendala pada pelayanan atau fungsi
sistem seperti kendala waktu, kendala proses
pengembangan, standard, dll. Contoh: kehandalan, waktu respon
dan kebutuhan
storage. Contoh kendala seperti: Keterbatasan kemampuan
peralatan I/O,
representasi sistem dll.
2.2. Sistem Analis
a) Dituntut untuk dapat memiliki Kemampuan :
a. Pemimpin Proyek
b. Mediator
c. Inovator
d. Arkeolog
b) Nama Lain : System Engineer, Chief System Designer,
Programmer/Analyst
dsb
Gambar 2.2 Cara Kerja Sistem Analis
c) Prinsip-Prinsip Analisis :
a. Domain Informasi dari masalah harus dapat direpresentasikan
dan
mudah dimengerti
b. Harus ada model yg dpt mengambarkan fungsi dan perilaku
sistem
c. Model dan masalah harus dapat dibuat bertingkat (dipartisi)
perinciannya
Clien
t Pengem
bang
Konsultan/Specifi
er
(Perancang
Senior)
-
Rekayasa Perangkat Lunak
20
d. Proses Analisis harus berpindah dari informasi dasar ke
perincian
implementasi
2.3. Domain Information
Tirdiri dari 3 pandangan : Information Flow, Information
Content, dan Information
Sructure
a) Information Flow mempresentasikan bagaimana data dan kontrol
berubah
dalam perjalananannya melalui sistem
b) Information Content merepresentasikan item-item individual
dari data dan
kontrol yang lebih besar
c) Information Structure merepresentasikan organisasi internal
dari item-item data
kontrol
Gambar 2.3 Struktur Informasi
2.4. Pemodelan
Harus dapat memodelkan informasi yang diolah oleh perangkat
lunak, fungsi dan
sub fungsi yang memungkinkan pengolahan dan perilaku sistem
ketika pengolahan
dilakukan. Dapat berupa notasi grafis atau tekstual.
1. Peranan Model :
a) Membantu analisis dalam pemahaman informasi fungsi dan dan
prilaku sistem
sehingga aktivtas analisis kebutuhan menjadi lebih mudah dan
lebih sistematis
Transform 1 Transfrom 2
Input
information
Output
information
Intermediate
information
Data Store
-
Rekayasa Perangkat Lunak
21
b) Merupakan poin kritis untuk peninjauan ulang yang penting
untuk kelengkapan,
konsistensi dan ketetapan dari spesifikasi
c) Merupakan dasar untuk tahap perancangan dengan menyediakan
kepada
perancang representasi dasar perangkat yang dapat dipetakan ke
dalam konteks
implementasi.
2. Pembagian
a) Berguna untuk penyederhanan
b) Proses pembagian
a. pembagian vertikal untuk memperinci fungsi
b. pembagian horisontal untuk dekomposisi fungsi
2.5. Informasi Dasar dan Implementasi
Informasi Dasar merepresentasikan fungsi yang ingin dicapai dan
informasi yang
akan diproses dengan mengabaikan perincian implementasi.
Perincian implementasi
merepresentasikan manifestasi dunia nyata dari fungsi pemrosesan
dan struktur
informasi
1. Kebutuhan Perangkat Lunak
Dapat dinyatakan dalam berbagai bentuk :
a) Gambar di atas kertas
b) Gambar di komputer ( dengan CASE Tool)
c) Prototype
d) Bahasa spesifikasi formal
2. Spesifikasi
a) Merupakan proses representasi dari kebutuhan sistem untuk
suksesnya
implementasi perangkat lunak
b) Balzer dan Goldman memberikan 8 prinsip spesifikasi yang
bagus, yaitu :
a. pisahkan fungsionalitas dari implementasi. Pusatkan pada
‘apa’ bukan
‘bagaimana’
b. dibutuhkan bhs spesifikasi sistem yang berorientasi pada
proses
c. spesifikasi harus mencakup sistem dimana perangkat lunak
adalah salah satu
komponen
-
Rekayasa Perangkat Lunak
22
d. spesifikasi harus meliputi lingkungan dimana sistem
beroperasi
e. spesifikasi sistem merupakan model kognitif
f. spesifikasi harus dapat dioperasionalkan
g. spesifikasi sistem harus toleran terhadap ketidaklengkapan
dan penambahan
h. spesifikasi harus terlokalisasi dan loosely coupled.
-
Rekayasa Perangkat Lunak
23
BAB III
ANALISA TERSTRUKTUR
3.1. Sejarah Analisa Terstruktur
1 Dipopularkan oleh DeMarco (1979)
2 Dikembangkan lebih lanjut oleh Page-Jones (1980), Gane dan
Sarson (1982)
3 Dikembangkan untuk sistem waktu nyata (Real Time) oleh Ward
dan Mellor
(1985) kemudian Hatley dan Pirbhai (1987)
4 Merupakan teknik pemodelan information flow dan information
content
3.2. Data Flow Diagram (DFD)
DFD atau yang sering disebut juga Bubble Chart, Bubble Diagram,
model proses,
diagram alur kerja, atau model fungsi, merupakan suatu diagram
yang menggambarkan
aliran data dalam sebuah sistem.
Komponen DFD terbagi menjadi 4:
1) Terminator atau External Entity
External Entity adalah lingkungan luar dari sistem tetapi dia
memiliki
pengaruh terhadap sistem. External Entity bisa digambarkan
sebagai individu,
kelompok, atau sistem lain (bukan orang).
Notasi :
2) Proses
Proses berfungsi untuk mentransformasikan data secara umum.
Karena proses
melakukan pekerjaan, maka dalam menamai sebuah proses dimulai
dengan
kata kerja dan diikuti objek.
Suatu proses harus memiliki input dan output. Suatu proses juga
dapat
dihubungkan dengan komponen External Entity, Data Store, atau
Proses lain
melalui Aliran Data.
Konsumen
-
Rekayasa Perangkat Lunak
24
Notasi :
Model DeMarco/Yourdon Model Gane & Sarson
3) Data Store
Data Store berfungsi menyimpan data/ file. Data store biasanya
berkaitan
dengan penyimpanan-penyimpanan secara komputasi, contoh:
harddisk,
disket, dvd disc, namun bisa juga berupa seperti buku, alamat,
agenda.
Data Store hanya dapat dihubungkan dengan komponen Proses
melalui Alur
Data, tidak dengan komponen DFD lain.
Notasi :
Model DeMarco/Yourdon Model Gane & Sarson
4) Alur Data
Alur Data menggambarkan aliran data dari suatu proses ke proses
lainnya.
Alur Data dapat merepresentasikan data/informasi yang berkaitan
dengan
komputer seperti bit, bilangan real, karakter, maupun yang tidak
seperti nama,
nim, alamat.
Notasi :
Diagram aliran data (DFD) memungkinkan perekayasa perangkat
lunak untuk
mengembangkan model domain informasi dan domain fungsional pada
saat yang sama.
Pada saat DFD disaring kedalam tingkah detail yang lebih tinggi,
analis melakukan
suatu dekomposisi fungsional implisit dari sistem, sehingga
memenuhi prinsip analisis
1
Periksa
Pesanan
1
Periksa
Pesanan
Pesanan Pesanan
Pesanan_barang
-
Rekayasa Perangkat Lunak
25
operasional keempat. Pada saat yang sama, penyaringan DFD
menghasilkan suatu
penyaringan yang sesuai dari data pada saat dia bergerak melalui
proses yang
membentuk aplikasi. Beberapa tuntunan sederhana dengan tak
terukur dapat membantu
selama derivasi sebuah diagram alir data:
1) Diagram aliran data tingkat 0 (Nol) harus menggambarkan
perangkat
lunak/sistem sebagai gelembung tunggal.
2) Input dan output utama harus dicatat secara hati-hati.
3) Penyaringan harus dimulai dengan mengisolasi proses calon,
objek data, dan
penyimpanan yang akan direpresentasikan pada tingkat
selanjutnya.
4) Semua anak panah dan gelembung harus diberi label dengan nama
yang berarti.
5) Satu gelembung pada suatu saat harus disaring.
Diagram Aliran Data Bertingkat
1. Dasar Pemikiran
a) ROSS
Pikiran manusia dapat menerima segala bentuk kerumitan, asalkan
disajikan
dalam susunan yang terdiri bagian-bagian kecil yang mudah
dimengerti
b) GEORGE MILLER
Pikiran manusia paling banyak dapat mengerti sesuatu yang
terbagi menjadi 7 +
2 bagian dan tetap masih dapat mengerti konsep dari sesuatu tadi
secara
keseluruhan .
2. Jenis DAD dalam DAD Bertingkat
a) Diagram konteks ( Context Diagram ): Diagram paling atas,
terdiri dari satu
proses dan mengambarkan ruang lingkup sisrtem.
b) Diagram Prinsif Fungsional ( Functional Primitive ):
Diagram-diagram paling
bawah, yang tidak dapat dibagi lagi atau memiliki masukan
tunggal dan
keluaran tunggal atau telah sangat sederhana ( narasi untuk
deskripsi dapat
dituliskan secara singkat ).
c) Diagran tengah: Diagram-diagram yang terletak antara Diagram
Konteks dan
Primitif Fungsional.
-
Rekayasa Perangkat Lunak
26
3. Penyusunan DAD
a. Penomoran
a) Diagram konteks biasanya diberi nomor 0
b) Proses-proses pada DAD paling atas diberi nomor mulai dari 1
dan seterusnya
sampai semua proses bernomor
c) Pada saat setiap proses dipecah menjadi DAD dengan tingkat
yang lebih
rendah, maka proses pada DAD tersebut diberi nomor sesuai dengan
nomor
proses tadi
d) Setiap proses diberi nomor yang merupakan kombinasi dari
nomor diagram
diikuti dengan nomor urut dalam tingkay yang bersangkutan.
b. Bentuk Umum Diagram Konteks :
R
S
Gambar 2.5 Bentuk umum diagram konteks
a) Nomor Diagram “ ANAK” harus diawali dengan nomor proses pada
diagram
‘ ORANG TUA “ yang terkait,
Diagram 0 Diagram 3
Gambar 2.6 Penomoran diagram konteks
TI
T2
O
SISTEM T3
1
2
3
3.1
3.2 3.3
AAA
Z
Z
Y
X
B
A X
Y
R
S
A
-
Rekayasa Perangkat Lunak
27
b) Dengan menyebutkan nomor diagram “ANAK “ yang sesuai dengan
nomor
proses diagram pada diagram “ ORANG TUA ‘ yang terkait . Nomor
proses
pada diagram ‘ ANAK “ boleh tidak diawali dengan nomor proses
diagram ‘
ORANG TUA ‘
c) Aturan Keseimbangan ( Balancing )
Semua aliran data yang masuk dan keluar diagram “ ORANG TUA’
harus
ada/sama pada diagram ‘ ANAK’
Diagram 0 Diagram 3
Gambar 2.7 Balancing DFD
4. Kamus Data
Sebuah daftar terorganisasi dari komposisi setiap elemen data,
aliran data, dan
penyimpanan data yang digunakan dalam sebuah DAD, serta
spesifikasi lojik dari
proses juga modul dan dekripsi modul dari Bagan Susunan dari
daftar dari Entitas dan
Relasi yang digunakan didalam Diagram E-R
Nama lain : Requirements Dictionary, Data Dictionary,
Encylopedia.
Mengapa diperlukan ?
Karena adanya kebutuhan untuk mendifinisikan isi dari :
a) Aliran Data ( DAD )
b) Penyimpanan Data
c) Proses ( DAD )
d) Entitas ( ERD )
e) Relasi (ERD)
1
2
3
.1
.2 .3
AAA
Z
Z
Y
X
B
A X
Y
R
S
A
-
Rekayasa Perangkat Lunak
28
5. Notasi Kamus Data
Tabel 2.1 Simbol notasi kamus data
SIMBOL ARTI
=
+
{}
[ ]
( )
* *
Terdiri dari
Dan
Iterasi
Pilihan salah Satu
Boleh ada, boleh tidak
Komentar
Contoh Kamus Data
a) Data : Nomor Telepon
Name : telephon number
aliases : none
where used/low used : access against set-up (output) dial
phone
(input)
description :
Telephone number = [ lokal extension | outside number ]
Lokal extension = [ 2001 | 2002 | …..| 2999 ]
Outside number = 9 + [ local number | long distance number ]
Local number = prefix + access number
Long distance number = ( 1 ) + area code + local number
Prefix = [ 795 | 799 | 874 | 877 ]
Access number = *any four number strings “
-
Rekayasa Perangkat Lunak
29
b) Arus Data : Surat Pengeluaran Barang
Nama Arus : Sales Order
Alias : SO
Bentuk Data : Cetakan komputer
Arus Data : Pelanggan – Proses pemesanan barang
Proses pemesanan – Data Store
Penjelasan : Untuk mencatat pemesanan barang
Periode : Setiap ada pesanan
Volume : Rata – rata tiap hari adalah 35
Struktur Data = HEADER + ISI + FOOTER
HEADER = No_SO + Tanggal + Tgl-PO + No PO Costumer +
Nama_Pelanggan +
Alamat + Telp
- No_SO : * Terdiri dari lima belas digit *
- Tanggal : Tanggal + Bulan + Tahun
- Nama_Plangan : (Titel) + Nama_depan + Nama_belakang
- Alamat : Jalan + Nomor + Kota
- Telepon : * Maksimal 14 digit *
ISI = 1 {KD_Item + Item + Nama_Barang + Satuan + Quantity +
Harga/Unit +
Disc (%) + Jumlah} 20
- item : * Nomor urut *
- Nama Barang : * Jenis barang yang dipesan *
- Satuan : * Maximal tiga digit *
- Harga/unit : * Dalam Rupiah *
-Quantity : * Dihitung dari unit dikali harga satuan
dikurangi
discount *
FOOTER = Total
- Total : * Total semua penjualan *
3.3. Entity Relationship Diagram (ERD)
Komponen dari ERD ada 6 yaitu
1) Entitas (Entity)
-
Rekayasa Perangkat Lunak
30
Entitas adalah suatu objek yang dapat dibedakan dari objek lain.
Suatu entitas
haruslah bersifat fakta. Entitas dapat berupa fisik, contoh:
Mobil, Rumah,
Gedung, dan dapat berupa konsep, contoh: Pekerjaan,
Perusahaan.
2) Atribut (Attribute)
Atribut merupakan properti yang dimiliki setiap entitas yang
datanya akan
disimpan. Contoh : atribut MAHASISWA -> NIM, Nama,
Alamat.
3) Relasi(Relationship)
Asosiasi antara satu atau lebih entitas. Berupa kata kerja.
4) Kardinalitas (Cardinality)
Gambar 3.1 Kardinalitas
5) Kardinalitas menunjukkan banyaknya objek yang terlibat dengan
objek lain pada
suatu relasi. Ada 3 kombinasi yang mungkin terjadi, diantaranya
: 1:1 (One to
One), 1:N (One to Many), dan N:M (Many to Many).
6) Modalitas (Modality)
Partisipasi sebuah entitas pada suatu relasi. 0 berarti
partisipasi parsial. 1 berarti
partisipasi total.
Diagram hubungan entitas memungkinkan seorang perekayasa
perangkat lunak untuk
secara penuh menspesifikasikan objek data yang merupakan input
dan output dari
sistem, atribut yang mendefinisikan sifat dari objek tersebut,
dan hubungan antar objek.
Seperti kebanyakan model analisis elemen, ERD dikonstruksi
didalam cara yang
iteratif. Pendekatan berikut ini diambil:
1) Selama pengumpulan persyaratan, pelanggan diminta untuk
mendaftar “hal-hal”
yang akan ditujuoleh proses bisnis dan aplikasi. “hal-hal” ini
dimasukan
kedalam sebuah daftar objek data input dan output dan entitas
eksternal yang
menghasilkan atau mengkonsumsi informasi.
-
Rekayasa Perangkat Lunak
31
2) Dengan mengambil objek satu pada satu saat, analis dan
pelanggan
mendefinisikan apakiah ada sambungan (tidak diberi nama pada
tahap ini) ada
diantara objek data dan objek lain.
3) Dimanapun sambungan ada, analis dan pelanggan menciptakan
satu pasangan
hubungan objek atau lebih.
4) Untuk masing-masing pasangan hubungan objek, dicari
kardinalitas dan
modalitas.
5) Langkah 2 sampai 4 dilanjutkan secara iteratif sampai semua
pasangan
hubungan objek sudah dudefinisikan. Sudah menjadi kebiasaan
untuk
menemukan penghilangan pada saat proses ini berlanjut. Objek dan
hubungan
baru akan ditambahkan pada saat jumlah iterasi bertambah.
6) Atribut dari masing-masing entitas didefinisikan.
7) Diagram hubungan entitas diformulasikan dan dikaji.
8) Langkah 1 sampai 7 diulang sampai pemodelan data
terlengkapi.
3.4. State Transition Diagram (STD)
STD merupakan diagram yang memodelkan tingkah laku (behaviour)
sistem
berdasarkan pada definisi satu bagian dari keadaan sistem. STD
sering dipakai untuk
menggambarkan kinerja sistem. Komponen STD dibagi menjadi 4
:
a. State
State merupakan kondisi dari suatu sistem. State dapat
dikategorikan
menjadi 2 macam, yaitu : State Awal dan State Akhir. State Awal
hanya
boleh berjumlah 1 state, dan State Akhir boleh memiliki jumlah
lebih dari
satu state.
b. State Change (Tanda Panah)
Menyatakan perubahan state dari sistem.
c. Kondisi
Kondisi menyatakan suatu kejadian pada lingkungan eksternal yang
dapat
dideteksi oleh sistem, contoh: sinyal.
-
Rekayasa Perangkat Lunak
32
d. Aksi
sistem melakukan sesuatu sehingga terjadi perubahan state atau
merupakan
suatu reaksi terhadap kondisi.
-
Rekayasa Perangkat Lunak
33
BAB IV
ANALISA DAN PERANCANGAN BERORIENTASI OBJEK
4.1. Konsep Umum Metodologi Berorientasi Objek
Ada beberapa tema yang mendasari teknologi berorientasi objek.
Meski tema-tema ini
tidak unik pada sistem berorientasi objek, mereka sangat
didukung pada metoda
analisis, perancangan serta implementasi dengan metodologi
berorientasi objek. Tema-
tema object oriented:
1. Kelas
Kelas membungkus (encapsulating) objek-objek. Suatu kelas
tunggal dapat
digunakan untuk menciptakansejumlah objek-objek. Selain itu,
suatu kelas juga
dapat digunakan untuk menciptakan kelas-kelas lain yang mewarisi
(inheritance)
sebagian atau seluruh data serta fungsi yang dimiliki oleh kelas
yang disebutkan
terdahulu.
2. Abstraksi
Abstraksi adalah menemukan hal-hal yang esensial pada suatu
objek dan
mengabaikan hal-hal yang sifatnya insidental. Maksudnya adalah
menangkap
sesuatu yang berarti untuk dituangkan sistem/perangkat lunak
alih-alih menangkap
seluruh fakta yang ada. Penggunaan konsep abstraksi selama
analisis berarti
“jangan pernah melakukan perancangan dan implementasi sebelum
persoalan
benar-benar dipahami”.
3. Pembungkusan (Encapsulation) dan Pengiriman Pesan (Message
Passing)
Pembungkusan berarti meninggalkan aspek eksternal dari objek
yang dapat
dimasuk (diakses) oleh objek lain dan memfokuskan diri pada
implementasi
internal suatu objek. Keuntungan pembungkusan adalah kita dapat
mengharapkan
suatu objek melakukan metoda apa yang kita inginkan tanpa harus
tahu bagaimana
objek itu melakukannya. Kita ibaratkan suatu objek dengan
televisi. Kita tidak
perlu tahu bagaimana televisi melakukan suatu tugas tertentu,
misalnya
menayangkan gambar tertentu, yang perlu kita ketahui
adalahtombol mana pada
remote control yang harus ditekan, kemudian televisi akan
berfungs. Penekanan
tombol pada remote control mengirim pesan tertentu ( baca
Message) pada televisi,
-
Rekayasa Perangkat Lunak
34
memberitahu metode apa yang akan dilakukan (pindah
saluran,mengeraskan suara,
meningkatkan intensitas warna tertentu dan sebagainya).
4. Generalisasi dan Polimorfisme
Generalisasi memungkinkan kelas-kelas berbagi data serta
perilaku yang sama.
Pada konteks pemrograman ini memungkinkan penguranganukuran kode
dan
menyediakan kemungkinan pengembangan sistem/perangkat lunak yang
lebih
mudah dipelihara. Polimorfisme mengijinkan penyesuaian berbagai
kode untuk
memenuhi keadaan tertentu.
5. Penggabungan Data (Atribut) dan Perilaku (Fungsi)
6. Sharing
7. Penekanan pada struktur objek, bukan pada struktur
prosedur
Teknologi berorientasi objek menekankan pada apa itu objek,
bukan pada
bagaimana objek itu digunakan.
8. Sinergis
Identitas, klasifikasi, polimorfisme serta pewarisan adalah
karakteristik utama dari
bahasa pemrograman berorientasi objek.
4.2. Konsep Dasar Analisis Berorientasi Objek
Gambar 4.1 Konsep dasar analisis berorientasi objek
Obyek inheritan pada
semua atributnya kelas Kelas : Mebel
Harga Dimensi Berat Lokasi Warna
Obyek : Kursi Harga Dimensi Berat
Lokasi
Warna
-
Rekayasa Perangkat Lunak
35
Konsep Dasar:
Object merupakan Entitas yang memiliki data yang menyatakan
kondisi pada suatu
saat, dan sekumpulan operasi yang dapat mengakses dan mengubah
kondisi tersebut.
Object, dapat berupa:
a. External Entities: sistem lain, alat atau orang yang memberi
atau memakai
informasi yang digunakan oleh sistem
b. Things: laporan tampilan, sinyal yang merupakan bagian dan
domain informasi
dari masalah.
c. Events or occurences: selesainya gerak robot.
d. Roles: manajer, staf teknik, staf pemasaran yang berperan
sebagai orang
berinteraksi dengan sistem.
e. Unit organisasi: divisi, kelompok. Tim yang berhubungan
dengan sistem.
4.3. Analisis Berorientasi Objek
Analisis berorientasi objek (OOA- Object Oriented Analysis)
adalah tahapan perangkat
lunak dengan menentukan spesifikasi sistem dan mengidentifikasi
kelas-kelas serta
hubungannya satu terhadap yang lain. Ivar Jaobson (dikutif dari
buku Object Oriented
System Development tulisan Ali Bahrawi, 1999) memperkenalkan
konsep use case
sebagai skenario untuk mrnjelaskan interaksi pengguna dengan
sistem
Analisis berorientasi objek memiliki 5 (lima) aktivitas:
1. Finding Class & Objects
2. Identifying Structures
3. Identifying Subjects
4. Defining Attributes
5. Defining Service
Ada 5 (lima) lapisan dalam analisis berorintasi objek:
1. Subject layer
2. Class & Onject layer
3. Structure layer
-
Rekayasa Perangkat Lunak
36
4. Attribute layer
5. Service layer
Identifikasi struktur dalam analisis berorientasi objek
1. Generalization Specialialization. (Gen-Spec) Structure dapat
dianggap sebagai ‘is a’ atau ‘is a kind of’.
2. Whole Part Struktur dapat dianggap sebagai ‘has a’
Whole Part
a) Sebuah pesawat merupakan assembly dari 0-4 mesin. Dan sebuah
mesin
merupakan bagian dari 0-1 pesawat
b) Sebuah organisasi merupakan kumpulan dari 0-n staf. Dan
seorang staf
merupakan bagian dari tepat 1 organisasi
Pesawat
Mesin
0-
4 0-1
Organisasi
Staf
0-n 1
-
Rekayasa Perangkat Lunak
37
4.3.1. Subject a. Masalah yang besar sebaiknya dibagi-bagi dalam
lingkup masalah yang lebih kecil
lagi.
b. Begitu pula dalam OO, kelas-kelas yang ada dapat di kumpulkan
dalam satu domain masalah tertentu.
c. Notasi :
4.3.2. Hubungan antar Kelas
2 jenis hubungan antar kelas
a) Intance Connection
merupakan suatu hubungan antar objek, dimana suatu objek
membutuhkan objek
lain untuk memenuhi tanggung jawabnya.
b) Message Connection
memodelkan suatu ketergantungan objek. Dimana suatu objek
membutuhkan
suatu service darri objek lain (biasanya dari class yang beda)
untuk memenuhi
tanggung jawabnya.
4.4. Perancangan Berorientasi Objek
Ada 4 aktivitas dalam perancangan berorientasi objek yaitu
1. Designing the Problem Domain Component
2. Designing the Human Interaction Component
3. Designing the Task Management Component
4. Designing the Data MC
Ada 4 komponen dalam perancangan berorientasi objek yaitu
1. Problem Domain Component (PDC)
2. Human Interaction Component (HIC)
3. Task Management Component (TMC)
4. Data Management Component (DMC)
1. Subject 1 1
1 1
1 1
-
Rekayasa Perangkat Lunak
38
Managemant Component terdiri dari:
Gambar 4.2 Management component
Bahasa Pemprograman Berorientasi Objek (C++)
1. Dikembangkan oleh AT&T Bell Lab.
2. Merupakan evolusi dari bahasa C.
3. Merupakan superset dari bahasa C.
4. Dikembangkan untuk :
a) mempertahankan efisiensi dan portabilitas bahasa C
b) mempertahankan kompatibilitas dengan bahasa C.
c) menutupi kekurangan pada bahasa C.
d) mempertajam penerapan konsep information hidding.
5. DEKLARASI “CLASS”
a) Makna pernyataan STRUCT diubah menjadi CLASS
Contoh : class ostream {
public:
FILE ‘file:
int nextchar:
char buf[128]:
}
b) Kata public menyebabkan ‘file, nextchar, buf’ dapat diakses
oleh semua
object dalam kelas yang sama.
c) Bila kata public tidak dinyatakan maka data ‘file, nextchar,
buf’ bersifat
private.
6. MEMBER FUNCTION
7. DEKLARASI FUNGSI
8. BASE CLASS
9. DRIVED CLASSES
Subject
Class & Object
Structure
Attribute
Service
-
Rekayasa Perangkat Lunak
39
BAB V
PEMODELAN DATA
Metode pemodelan data menggunakan ERD (Entity Relationship
Diagram). Dengan
ERD memungkinkan perekayasa perangkat lunak mengidentifikasi
objek data dan
hubungannya dengan menggunakan notasi grafis. ERD hanya berfokus
pada data,
dengan menunjukan “jaringan data” yang ada untuk suatu sistem
yang diberikan. ERD
sangat berguna bagi aplikasi dimana data dan hubungan yang
mengatur data sangatlah
kompleks.tidak seperti diagram alir data, pemodelan data melihat
secara independen
dari pemprosesan yang memtransformasikan data tersebut.
1. ERD merupakan model jaringan yang menggunakan susunan data
yang disimpan
dalam sistem secara abstrak
2. Diagram E-R berupa model data konseptual, yang
merepresentasikan data dalam
suatu organisasi.
3. ERD menekankan pada struktur dan relationship data, berbeda
dengan DFD(Data
Flow Diagram) yang merupakan model jaringan fungsi yang akan
dilaksanakan
sistem
4. Biasanya digunakan oleh profesional sistem untuk
berkomunikasi dengan pemakai
eksekutif tingkat tinggi dalam perusahaan yang tidak tertarik
pada pelaksanaan
operasi sistem sehari-hari, namun lebih kepada :
a. Data apa saja yang diperlukan untuk bisnis mereka?
b. Bagaimana data tersebut berelasi dengan data lainnya?
c. Siapa saja yang diperbolehkan mengakses data tsb?
-
Rekayasa Perangkat Lunak
40
Notasi Yang digunakan pada perancangan E-R diagram
Gambar 5.1 Simbol-simbol ERD
Contoh ER diagram terlampir.
Gambar 5.2 Contoh ERD
latihan
Rancanglah diagram E-R dari kasus aplikasi database
sederhanauntuk sistem informasi
akademis suatu universitas.
Dengan ketentuan sebagai berikut :
Entities yang dimuat adalah :
1. mahasiswa: menyimpan semua informasi pribadi mengenai semua
mahasiswa
2. dosen: menyimpan semua informasi pribadi mengenai semua
dosen
Memasok
BARANG
Mengirim
KIRIMAN Memasok
PEMASOK
Digunakan_
pada
PRODUK
Beris
i
PESANAN
Mengirim
PELANGGA
N
ENTITAS
Hubungan
Kardinalitas:
Selalu hanya satu
Satu atau banyak
Nol atau satu
Nol, satu, atau banyak
Atribut
-
Rekayasa Perangkat Lunak
41
3. mata_kuliah: menyimpan semua informasi mengenai semua mata
kuliah yang
ditawarkan
4. ruang: menyimpan semua informasi mengenai ruang kelas yang
digunakan
-
Rekayasa Perangkat Lunak
42
BAB VI
DASAR-DASAR PERANCANGAN PIRANTI LUNAK
6.1. Prinsip Dasar Perancangan Perangkat Lunak
Perancangan Perangkat Lunak merupakan proses penerjemahan dari
kebutuhan menjadi
perangkat lunak. Hasil dari perancangan adalah :
1. Rancangan data yang memetakan model domain informasi pada
saat analisis
menjadi struktur data yang dibutuhkan untuk implementasi
perangkat lunak.
2. Rancangan arsitektural yang mendefinisikan hubungan dari
komponen-komponen
struktural utama dari program.
3. Rancangan prosedural yang memetakan komponen-komponen
struktural ke
deskripsi prosedur perangkat lunak
ABSTRACTION ( Wasserman )
1. Pada rancangan secara modular, beberapa tingkatan abstraksi
dapat diperoleh,
sehingga perancang dapat mengkonsen- trasikan pada setiap
tingkatan abstraksi
yang lebih terinci.
2. Pada level paling tinggi, solusi dinyatakan secara global
dengan bahasa pada
lingkungan masalah. Dan pada abstraksi paling bawah, solusi
dinyatakan dalam
bahasa yang dapat langsung diimplementasikan.
Contoh Abstraksi Program dan Abstraksi Data :
PROGRAM ABSTRACTION
Abstraksi tingkat pertama :
CAD Software Task
User interface Task
2-D Drawing Creation Task
………
end.
Abstraksi tingkat kedua :
PROCEDURE User interface
………
……
End
DATA ABSTACTION
TYPE drawing IS STRUCTURE
DEFINED
Number IS INTEGER
Icon IS ICON_STRUCTURE
Notes IS STRING LENGTH (225)
Versi IS STRING LENGTH ( 10 )
……………
end
-
Rekayasa Perangkat Lunak
43
MODULARITY & SOFTWARE ARCHITECTURE
1. Perangkat lunak dibagi atas beberapa modul.
2. Sebuah modul dapat dibagi lagi atas beberapa sub-modul
3. Modul memiliki nama yang unik.
4. Sebuah modul dapat memanggil modul lainya.
Gambar 6.1 Struktur Evolusi
Gambar 6.2 Struktur Berbeda
S1 S2
S4
S3
S5
Software “solution” “Problem” to be solved via software
P S
5S
4S
1
S3
S2
S4
S1
S3
S5
S2
S4
S2
S3
S5
S1
“Problem”
Structure 1 Structure 2 Structure 3
-
Rekayasa Perangkat Lunak
44
Gambar 6.3 Struktur Terminologi
HIRARKI KONTROL ( STRUKTUR PROGRAM )
1. Menunjukkan organisasi dari modul-modul program dan
menunjukan hirarki
kontrolnya. Tidak merepresentasikan aspek prosedural dari
perangkat lunak seperti
urutan proses, keputusan, atau perulangan.
2. Kedalaman dan lebar menunjukkan jumlah tingkatan kontrol dan
seluruh cakupan
kontrol
3. Fan-out menunjukkan jumlah modul yang secara langsung
dikontrol oleh modul
lain
4. Fan-in menunjukkan jumlah modul yang mengontrol modul yang
bersangkutan
5. Modul yang mengontrol modul yang lain disebut
superordinate
6. Modul yang dikontrol modul yang lain disebut subordinate
FAN-OUT
1. Fan-out dari sebuah modul adalah banyaknya subordinate
langsung dari modul
tersebut
2. Perluasan kontrol dari sebuah modul sebaiknya tidak melebihi
7 + 2 ( kecuali pada
pusat-pusat transaksi )
3. Hindarkan Fan-out yang bersifat main-line (satu boss, dengan
modul-modul lain
sebagai subordinate )
Depth
Width
Fan-out
Fan-in
M
b c a
k d e l m
g f h o n p q
i j r
-
Rekayasa Perangkat Lunak
45
4. Sebuah modul dengan Fan-out yang banyak biasanya sukar
dipelihara.
5. Untuk memecahkan fan-out yang banyak gunakan modul-modul
antara
FAN-IN
1. Fan-in dari modul adalah banyaknya modul lain yang ( boss
)
menggunakan/memanggil modul tersebut.
2. Jika mungkin Fan-in harus dilakukan sebanyak-banyaknya.
3. Fan-in yang banyak menghindari pengulangan pembuatan modul
yang sama atau
serupa
4. Fan-in yang banyak mempermudah pemeliharaan karena
menempatkan suatu fungsi
yang sama dalam satu modul
STRUKTUR DATA
Refresentasi lojikal dari hubungan antara elemen-elemen
data.
Gambar 6.4 Struktur Data Klasik
A linked list
A scalar item
A scalar item
…
An N-dimensional space
…
…
A hierarchical tree
-
Rekayasa Perangkat Lunak
46
PROSEDUR PERANGKAT LUNAK
Struktur program hanya mendefinisikan hirarki kontrol tanpa
memperhatikan urutan
proses. Prosedur perangkat lunak berfokus pada rincian proses
dari setiap modul.
INFORMATION HIDING ( by Pamas )
Prinsip dasar dalam pembentukan modul dimana hanya data yang
benar-benar perlu,
yang dikenalkan dan dapat diakses oleh sebuah modul.
Gambar 6.5 Prosedur Berlapis
Module
A
Module
A
Prosedur di dalam
suatu modul
-
Rekayasa Perangkat Lunak
47
6.2. PERANCANGAN YANG MODULAR
1. Keuntungan :
a) menurunkan kompleksitas
b) mempermudah pengubahan
c) implementasi yang lebih mudah karena bagian-bagian yang
berbeda dapat dibuat
dengan paralel
2. Evaluasi dari hubungan antar modul dapat dinilai dengan
melihat kohesi dan
koplingnya ( Steven, Myers, dan Constantine )
KOPLING
1. Kopling adalah tingkat saling ketergantungan antara dua
modul.
2. Kita menghendaki modul dengan kopling rendah yaitu
modul-modul yang sedapat
mungkin tidak saling bergantungan.
3. Kopling yang rendah adalah tanda dari pembagian sistem yang
baik, dimana
sesuatu yang tidak berhubungan dipisahkan.
4. Jika sedikit atau tidak ada interaksi dua modul disebut
loosely coupled (kopling
rendah) dan jika sebaliknya disebut tighty coupled (kopling
tinggi)
5. Makin tinggi kopling yang ada makin sulit sebuah program
untuk dimengerti.
6. Jika dua modul memiliki kopling yang rendah, maka sebuah
modul dapat diubah
tanpa perlu mengubah modul yang lain.
7. Mengapa kopling yang rendah diperlukan ?
Untuk menghilangkan ripple effect (perubahan pada sebuah modul
dapat
berpengaruh pada modul lain). Sehingga dapat memelihara atau
mengubah suatu
modul dengan resiko yang minimal untuk mengubah modul lainnya.
Jika mungkin
kita ingin dapat bekerja dengan modul A tanpa perlu mengetahui
tentang apapun
dalam modul B.
8. Faktor-faktor yang berpengaruh pada kopling antara dua modul
adalah :
a) Jumlah item data yang disalurkan diantara dua modul (makin
banyak data yg
disalurkan makin tinggi kopling yang terjadi).
b) Jumlah data kontrol yang disalurkan diantara dua modul (makin
banyak data
kontrol yang disalurkan makin tinggi kopling yang terjadi)
-
Rekayasa Perangkat Lunak
48
X
X
Y
Y
Lalu lintas jalan
Kopling rendah Kohesi tinggi
Y
X
X
Y
Lalu lintas jalan
Kopling tinggi Kohesi rendah
c) Jumlah elemen data global yang digunakan bersama-sama oleh
beberapa modul
(makin banyak data global yang digunakan, makin tinggi kopling
yang terjadi)
KOHESI
1. Melekatkan hal-hal yang berkaitan didalam modul yang sama,
akan mengurangi
lalu-lintas diantara modul-modul .
2. Apa yang terjadi diantara modul-modul (kopling) dipengaruhi
oleh apa yang terjadi
dalam modul-modul tersebut secara individual (kohesi)
3. Kohesi adalah ukuran kekuatan asosiasi antar elemen didalam
suatu modul.
4. Elemen yang dimaksud adalah : sebuah instruksi, sekumpulan
intruksi, atau
pemanggilan ke modul lain.
5. Kohesi tinggi jika sebuah modul hanya bertanggung jawab
terhadap satu pekerjaan
saja.
Gambar 6.6 Kohesi
6.3. RANCANGAN DATA
1. Rancangan data yang bagus dapat membuat struktur program
lebih baik,
modularitas efektif dan menurunkan kompleksitas prosedural
2. Beberapa petunjuk :
a) Semua struktur data dan operasi yang mengolahnya harus
didefinisikasi
b) Selalu gunakan kamus data
-
Rekayasa Perangkat Lunak
49
c) Rancanagan data yang bersifat low-level harus ditunda sampai
akhir dari
proses perancangan
d) Bentuk keputusan dan struktur data dan operasi-operasi yang
mengolahnya
e) Bahasa pemrograman harus mendukung spesifikasi dan realisasi
dari tipe data
abstrak.
6.4. PERANCANGAN ARSITEKTURAL
Tujuan dari perancangan arsitektural adalah untuk membangun
struktur program yang
modular dan membentuk hubungan kontrol antar modul. Rancangan
arsitektural
menggabungkan struktur program dan struktur data serta
mendefinisikan interface yang
membuat data melalui program. Dan dinyatakan dalam bentuk Bagan
Susunan atau
diagram Wamier/Orr.
BAGAN SUSUNAN (Structured Chart)
1. Bagan susunan merupakan susunan hirarki dari modul-modul
2. Bagan susunan menunjukkan
a) pembagian sistem menjadi modul-modul
b) hirarki dan organisasi modul-modul
c) komunikasi antar modul ( masukan dan keluaran )
d) nama modul, yang berarti juga fungsi modul.
3. Bagan Susunan tidak menunjukkan :
a) Mekanik didalam modul ( seperti ukuran pemanggilan modul
lain, loops dsb )
b) Data internal dari modul
Simbol-simbol yang digunakan :
Gambar 6.7 Simbol-simbol bagan terstruktur
: hubungan 2
: pengulangan 3
: Seleksi / pemilihan 4
: Kopel Kontrol 5
: Kopel Data 6
: Nama Modul / Proses 1
-
Rekayasa Perangkat Lunak
50
Contoh :
Menunjukkan suatu model dengan nama “Hitung Potongan”.
Modul A memanggil modul B. Setelah proses dari modul B selesai,
maka proses
kembali ke modul A yang memanggilnya.
Modul A memanggil modul B dan elemen data P dikirimkan dari
modul A ke modul B.
Hasil proses dari modul B mengirimkan elemen data Q dan elemen
kontrol Flag ke
modul A.
-
Rekayasa Perangkat Lunak
51
Modul A memanggil modul B bila kondisi yang diseleksi di modul
terpenuhi. Modul A
juga memanggil modul C berulang kali yang ditunjukkan oleh
simbol perulangan.
Model Bagan Terstruktur
Terdapat dua model dari bagan terstruktur, yaitu
transformed-centered dan transaction
centered. Bagan terstruktur dapat berbentuk model
transformed-centered saja atau
transaction centered saja atau kombinasi dari keduanya. Model
yang digunakan ini
tergantung dari diagram arus data yang telah dibuat, karena
bagan terstruktur
digambarkan berdasarkan diagram arus data (DAD).
a. Transformed-centered
Bagan terstruktur dengan model transformed-centered
menggambarkan sistem
dalam 3 cabang utama, yaitu sebagai berikut :
1. Cabang input (input branch) atau disebut juga dengan
affrerent branch,
merupakan cabang yang menerima input dan membentuk input kedalam
suatu
status yang siap untuk diproses.
2. Cabang proses (process branch) atau disebut juga dengan
cabang transformasi
(transform branch) atau disebut juga dengan central transform,
merupakan
cabang yang akan melakukan fungsi utama dari sistem, yaitu
memperoses
input yang dikirim dari cabang input.
3. Cabang output (output branch) atau disebut juga dengan
efferent branch,
merupakan cabang yang akan memformat data menjadi output.
-
Rekayasa Perangkat Lunak
52
Gambar 6.8 Model dasar bagan terstruktur
transformed-centered
b. Transaction-centered
Seringkali diagram arus data menggambarkan suatu sistem yang
menangani
beberapa tipe transaksi yang mempunyai jalur yang berbeda.
Diagram tersebut
mungkin akan sulit dipilah-pilah berdasarkan transformasinya.
Untuk diagram alur
data tersebut, dapat dibuat bagan terstruktur model
transaction-centered.
-
Rekayasa Perangkat Lunak
53
Gambar 6.9 Model bagan terstruktur jenjang dari
transaction-centered
Contoh :
-
Rekayasa Perangkat Lunak
54
TABEL KEPUTUSAN
Tabel keputusan (decision table) adalah tabel yang digunakan
sebagai alat bantu untuk
menyelesaikan logika dalam program
Condition Stub
◦ Bagian ini berisi kondisi yang akan diseleksi.
Condition Entry
◦ Bagian ini berisi kemungkinan dari kondisi yang diseleksi,
yaitu
terpenuhi (diberi simbol ‘Y’) dan tidak terpenuhi (diberi simbol
‘N’).
◦ Bila ada kondisi X diseleksi, terdapat N Kemungkinan terjadi N
= 2X
Action Stub
◦ Action stub berisi pernyataan-pernyataan yang akan dikerjakan
baik
kondisi yang diselesi terpenuhi maupun tidak terpenuhi.
Action Entry
◦ Action entry digunakan untuk memberi tanda tindakan mana yang
akan
dilakukan dan mana yang tidak akan dilakukan
-
Rekayasa Perangkat Lunak
55
DIAGRAM KEPUTUSAN
Merupakan model dari sebuah fungsi diskrit dimana nilai dari
sebuah variabel
ditentukan; berdasarkan nilai ini beberapa tindakan
dilakukan
-
Rekayasa Perangkat Lunak
56
BAHASA TERSUSUN
Konteks Logik :
BIT/SE merupakan jembatan antara analisis perancangan dan
pengkodean
BIT/SE adalah bahasa spesifikasi yang menggunakan perbendaraan
kata dan
sintaks yang terbatas
Perbendaharaan katanya hanya terdiri dari :
◦ Kata kerja perintah/Imperative language verb.
◦ Istilah yang didefinisikan dalam Kamus Data.
◦ Reserved Word tertentu untuk formulasi logik.
Contoh :
JIKA MASA-KERJA LEBIH DARI 15 TAHUN
MAKA
BONUS = 100.000
SELAIN ITU
BONUS = 50.000
AKHIR JIKA
-
Rekayasa Perangkat Lunak
57
DIAGRAM ALIR/FLOWCHART
BOX DIAGRAM/N-S CHART
-
Rekayasa Perangkat Lunak
58
Contoh :
-
Rekayasa Perangkat Lunak
59
6.5. RANCANGAN PROSEDURAL
Rancangan prosedural dilakukan setelah struktur program dan data
telah dibentuk.
Beberapa bentuk pernyataan :
1. pemrograman terstruktur
2. notasi grafis : flowchart, box diagram/N-S charts
3. bentuk tabel
4. PDL
KARAKTERISTIK NOTASI PERANCANGAN
1. Mendukung modularistas
2. Sederhana
3. Mudah diubah
4. Dapat dibaca oleh mesin
5. Dapat dipelihara
6. Structured enforcerment
7. Code-to-ability
8. Dapat diverifikasi
Beberapa Pedoman
1. Pemakai sistem harus selalu mengetahui apa yang mesti
dilakukan berikutnya
a) beritahu pemakai apa yang diharapkan oleh sistem sekarang
Contoh : SIAP,
MASUKKAN PERINTAH, MASUKKAN PILIHAN atau MASUKKAN
DATA.
b) Beritahu pemakai bahwa data telah dimasukkan dengan benar,
Bisa berupa
perpindahan kursor ke data berikutnya atau pesan : MASUKKAN
VALID
c) Beritahu pemakai bahwa pemasukkan data salah. Pemberitahuan
format yang
benar lebih baik.
2. Bentuk pemakaian alasan adanya delay dalam pemrosesan.
Contoh : SORTING, PLEASE STAND BY, INDEXING, PLEASE WAIT,
THIS
MAY TAKE A FEW MINUTES, TUNGGU SEBENTAR, Adanya pesan
membuat
pemakai mengetahui bahwa sistem tidak gagal.
-
Rekayasa Perangkat Lunak
60
3. Beritahu pemakai sebuah pekerjaan selesai atau tidak selesai
dilakukan Contoh :
PRINTING, COMPLETE, PRINTER NOT READY – PLEASE CHECK AND
TRY AGAIN.
Rancangan Layar :
1. Layar sebaiknya diatur agar beberapa tipe informasi, intruksi
dan pesan selalu
muncul di area yang konsisten. Ini akan membantu pemakai mencari
informasi
yang spesifik
2. Perancangan layar yang terlalu “ norak “
3. Berikan kesempatan pemakai menghemat pengetikan dengan
function keys
4. Jika memungkinkan, berikan harga baku
5. Antisipasi kesalahan yang mungkin dibuat oleh pemakai.
a. Contoh : YAKIN DIHAPUS ?
6. Selalu Konsisten
7. Kurang jumlah informasi yang harus diingat diantaranya
aksi
Penulisan Program
1. Cobalah untuk langsung menggunakan keistimewaan yang ada pada
bahasa
pemrograman
2. Cobalah untuk menggunakan library dan fungsi-fungsi yang
telah ada pada bahasa
pemrograman
3. Jangan mengabaikan pesan-pesan peringatan ( warning message
)
Beberapa pedoman Bahasa
1. Sederhana, dan benar secara aturan bahasa.
o Bahasa percakapan lebih baik daripada bahasa tulisan
2. Jangan berusaha melucu atau “ sok imut “.
o jika penggunaan harus memakainya 25x seharai. Akan tidak lucu
lagi.
3. Jangan menyinggung intelegensia pemakai
-
Rekayasa Perangkat Lunak
61
Penulisan Pemrograman
1. Jumlah perintah dalam suatu subprogram sebaiknya 5 – 100
perintah
2. Jumlah paremeter yang di-pass sebaiknya
-
Rekayasa Perangkat Lunak
62
c) COBOL, 4GL untuk aplikasi bisnis
d) FORTRAN untuk aplikasi sains dan teknik
e) PASCAL, C untuk program-program aplikasi di PC
f) LISP, PROLOG untuk kecerdasan buatan
-
Rekayasa Perangkat Lunak
63
BAB VII
PENGANTAR UML (Unified Modeling Language)
7.1. Definisi UML
Unified Modelling Language (UML) adalah sebuah "bahasa" yg telah
menjadi standar
dalam industri untuk visualisasi, merancang dan
mendokumentasikan sistem piranti
lunak. UML menawarkan sebuah standar untuk merancang model
sebuah sistem.
Dengan menggunakan UML kita dapat membuat model untuk semua
jenis aplikasi
piranti lunak, dimana aplikasi tersebut dapat berjalan pada
piranti keras, sistem operasi
dan jaringan apapun, serta ditulis dalam bahasa pemrograman
apapun. Tetapi karena
UML juga menggunakan class dan operation dalam konsep dasarnya,
maka ia lebih
cocok untuk penulisan piranti lunak dalam bahasa berorientasi
objek seperti C++, Java,
C# atau VB.NET. Walaupun demikian, UML tetap dapat digunakan
untuk modeling
aplikasi prosedural dalam VB atau C. Seperti bahasa-bahasa
lainnya, UML
mendefinisikan notasi dan syntax/semantik. Notasi UML merupakan
sekumpulan
bentuk khusus untuk menggambarkan berbagai diagram piranti
lunak. Setiap bentuk
memiliki makna tertentu, dan UML syntax mendefinisikan bagaimana
bentuk-bentuk
tersebut dapat dikombinasikan. Notasi UML terutama diturunkan
dari 3 notasi yang
telah ada sebelumnya: Grady Booch OOD (Object-Oriented Design),
Jim Rumbaugh
OMT (Object Modeling Technique), dan Ivar Jacobson OOSE
(Object-Oriented
Software Engineering). Sejarah UML sendiri cukup panjang. Sampai
era tahun 1990
seperti kita ketahui puluhan metodologi pemodelan berorientasi
objek telah
bermunculan di dunia. Diantaranya adalah: metodologi booch [1],
metodologi coad [2],
metodologi OOSE [3], metodologi OMT [4], metodologi
shlaer-mellor [5], metodologi
wirfs-brock [6], dsb. Masa itu terkenal dengan masa perang
metodologi (method war)
dalam pendesainan berorientasi objek. Masing-masing metodologi
membawa notasi
sendiri-sendiri, yang mengakibatkan timbul masalah baru apabila
kita bekerjasama
dengan group/perusahaan lain yang menggunakan metodologi yang
berlainan.
Dimulai pada bulan Oktober 1994 Booch, Rumbaugh dan Jacobson,
yang merupakan
tiga tokoh yang boleh dikata metodologinya banyak digunakan
mempelopori usaha
untuk penyatuan metodologi pendesainan berorientasi objek. Pada
tahun 1995 direlease
draft pertama dari UML (versi 0.8). Sejak tahun 1996
pengembangan tersebut
-
Rekayasa Perangkat Lunak
64
dikoordinasikan oleh Object Management Group (OMG –
http://www.omg.org).
Tahun 1997 UML versi 1.1 muncul, dan saat ini versi terbaru
adalah versi 1.5 yang
dirilis bulan Maret 2003. Booch, Rumbaugh dan Jacobson menyusun
tiga buku serial
tentang UML pada tahun 1999 [7] [8] [9]. Sejak saat itulah UML
telah menjelma
menjadi standar bahasa pemodelan untuk aplikasi berorientasi
objek.
7.2. Konsep Dasar UML
Gambar 7.1 Konsep Dasar UML
Abstraksi konsep dasar UML yang terdiri dari structural
classification, dynamic
behavior, dan model management, bisa kita pahami dengan mudah
apabila kita melihat
gambar diatas dari Diagrams. Main concepts bisa kita pandang
sebagai term yang akan
muncul pada saat kita membuat diagram. Dan view adalah kategori
dari diagaram
tersebut. Lalu darimana kita mulai ? Untuk menguasai UML,
sebenarnya cukup dua hal
yang harus kita perhatikan:
1. Menguasai pembuatan diagram UML
2. Menguasai langkah-langkah dalam analisa dan pengembangan
dengan UML
Tulisan ini pada intinya akan mengupas kedua hal tersebut.
Seperti juga tercantum pada
gambar diatas UML mendefinisikan diagram-diagram sebagai
berikut:
a) use case diagram
b) class diagram
-
Rekayasa Perangkat Lunak
65
c) statechart diagram
d) activity diagram
e) sequence diagram
f) collaboration diagram
g) component diagram
h) deployment diagram
7.2.1. Use Case Diagram
Use case diagram menggambarkan fungsionalitas yang diharapkan
dari sebuah sistem.
Yang ditekankan adalah “apa” yang diperbuat sistem, dan bukan
“bagaimana”. Sebuah
use case merepresentasikan sebuah interaksi antara aktor dengan
sistem. Use case
merupakan sebuah pekerjaan tertentu, misalnya login ke sistem,
meng-create sebuah
daftar belanja, dan sebagainya. Seorang/sebuah aktor adalah
sebuah entitas manusia
atau mesin yang berinteraksi dengan sistem untuk melakukan
pekerjaan-pekerjaan
tertentu. Use case diagram dapat sangat membantu bila kita
sedang menyusun
requirement sebuah sistem, mengkomunikasikan rancangan dengan
klien, dan
merancang test case untuk semua feature yang ada pada sistem.
Sebuah use case dapat
meng-include fungsionalitas use case lain sebagai bagian dari
proses dalam dirinya.
Secara umum diasumsikan bahwa use case yang di-include akan
dipanggil setiap kali
use case yang meng-include dieksekusi secara normal. Sebuah use
case dapat di-include
oleh lebih dari satu use case lain, sehingga duplikasi
fungsionalitas dapat dihindari
dengan cara menarik keluar fungsionalitas yang common. Sebuah
use case juga dapat
meng-extend use case lain dengan behaviour-nya sendiri.
Sementara hubungan
generalisasi antar use case menunjukkan bahwa use case yang satu
merupakan
spesialisasi dari yang lain. Contoh use case diagram:
-
Rekayasa Perangkat Lunak
66
Gambar 7.2 Contoh Use Case
7.2.2. Class Diagram
Class adalah sebuah spesifikasi yang jika diinstansiasi akan
menghasilkan sebuah objek
dan merupakan inti dari pengembangan dan desain berorientasi
objek. Class
menggambarkan keadaan (atribut/properti) suatu sistem, sekaligus
menawarkan layanan
untuk memanipulasi keadaan tersebut (metoda/fungsi). Class
diagram menggambarkan
struktur dan deskripsi class, package dan objek beserta hubungan
satu sama lain seperti
containment, pewarisan, asosiasi, dan lain-lain. Contoh class
diagram:
Gambar 7.3 Contoh Class Diagram
-
Rekayasa Perangkat Lunak
67
7.2.3. Activity Diagram
Activity diagrams menggambarkan berbagai alir aktivitas dalam
sistem yang sedang
dirancang, bagaimana masing-masing alir berawal, decision yang
mungkin terjadi, dan
bagaimana mereka berakhir. Activity diagram juga dapat
menggambarkan proses paralel
yang mungkin terjadi pada beberapa eksekusi. Activity diagram
merupakan state
diagram khusus, di mana sebagian besar state adalah action dan
sebagian besar transisi
di-trigger oleh selesainya state sebelumnya (internal
processing). Oleh karena itu
activity diagram tidak menggambarkan behaviour internal sebuah
sistem (dan interaksi
antar subsistem) secara eksak, tetapi lebih menggambarkan
proses-proses dan jalur-jalur
aktivitas dari level atas secara umum. Sebuah aktivitas dapat
direalisasikan oleh satu use
case atau lebih. Aktivitas menggambarkan proses yang berjalan,
sementara use case
menggambarkan bagaimana aktor menggunakan sistem untuk melakukan
aktivitas.
Sama seperti state, standar UML menggunakan segiempat dengan
sudut membulat
untuk menggambarkan aktivitas. Decision digunakan untuk
menggambarkan behaviour
pada kondisi tertentu. Untuk mengilustrasikan proses-proses
paralel (fork dan join)
digunakan titik sinkronisasi yang dapat berupa titik, garis
horizontal atau vertikal.
Activity diagram dapat dibagi menjadi beberapa object swimlane
untuk menggambarkan
objek mana yang bertanggung jawab untuk aktivitas tertentu.
Contoh activity diagram
tanpa swimlane:
Gambar 7.3 Contoh Activity Diagram
-
Rekayasa Perangkat Lunak
68
7.2.4. Sequence Diagram
Sequence diagram menggambarkan interaksi antar objek di dalam
dan di sekitar sistem
(termasuk pengguna, display, dan sebagainya) berupa message yang
digambarkan
terhadap waktu. Sequence diagram terdiri atar dimensi vertikal
(waktu) dan dimensi
horizontal (objek-objek yang terkait). Sequence diagram biasa
digunakan untuk
menggambarkan skenario atau rangkaian langkah-langkah yang
dilakukan sebagai
respons dari sebuah event untuk menghasilkan output tertentu.
Diawali dari apa yang
men-trigger aktivitas tersebut, proses dan perubahan apa saja
yang terjadi secara
internal dan output apa yang dihasilkan. Masing-masing objek,
termasuk aktor,
memiliki lifeline vertikal. Message digambarkan sebagai garis
berpanah dari satu objek
ke objek lainnya. Pada fase desain berikutnya, message akan
dipetakan menjadi
operasi/metoda dari class. Activation bar menunjukkan lamanya
eksekusi sebuah
proses, biasanya diawali dengan diterimanya sebuah message.
Untuk objek-objek yang
memiliki sifat khusus, standar UML mendefinisikan icon khusus
untuk objek boundary,
controller dan persistent entity. Contoh sequence diagram:
Gambar 7.4 Contoh Sequence Diagram
-
Rekayasa Perangkat Lunak
69
7.2.5. Tool Yang Mendukung UML
Saat ini banyak sekali tool pendesainan yang mendukung UML, baik
itu tool komersial
maupun opensource. Beberapa diantaranya adalah:
1) Rational Rose (www.rational.com)
2) Together (www.togethersoft.com)
3) Object Domain (www.objectdomain.com)
4) Jvision (www.object-insight.com)
5) Objecteering (www.objecteering.com)
6) MagicDraw (www.nomagic.com/magicdrawuml)
7) Visual Object Modeller (www.visualobject.com)
http://www.visualobject.com/
-
Rekayasa Perangkat Lunak
70
BAB VIII
PENGUJIAN PERANGKAT LUNAK
Saat ini sudah banyak berkembang berbagai metode untuk pengujian
perangkat lunak.
Metode-metode tersebut memberikan pendekatan yang sistematik
untuk pengujian
perangkat lunak kepada pengembang. Selain itu, metode-metode
tersebut memberikan
mekanisme yang dapat membantu memastikan kelengkapan pengujian
dan memberikan
kemungkinan tertinggi untuk mengungkap kesalahan pada perangkat
lunak.
Semua produk yang direkayasa dapat diuji dengan satu atau dua
cara, yaitu:
1) Dengan mengetahui fungsi yang ditentukan untuk dilakukan oleh
suatu produk,
pengujian dapat dilakukan untuk memperlihatkan bahwa
masing-masing fungsi
beroperasi sepenuhnya dan pada waktu yang sama mencari kesalahan
pada setiap
fungsi
2) Dengan mengetahui kerja internal suatu produk, maka pengujian
dapat dilakukan
untuk memastikan bahwa seluruh operasi internal bekerja sesuai
spesifikasi dan
semua komponen internal telah diamati dengan memadai
Pendekatan pengujian perta