-
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